作者|绘你一世倾城
每到节假日期间,一二线城市返乡、外出游玩的人们几乎都面临着一个问题：抢火车票！
虽然现在大多数情况下都能订到票，但是放票瞬间即无票的场景，相信大家都深有体会。
尤其是春节期间，大家不仅使用12306，还会考虑“智行”和其他的抢票软件，全国上下几亿人在这段时间都在抢票。
“12306服务”承受着这个世界上任何秒杀系统都无法超越的QPS，上百万的并发再正常不过了！
笔者专门研究了一下“12306”的服务端架构，学习到了其系统设计上很多亮点，在这里和大家分享一下并模拟一个例子：如何在100万人同时抢1万张火车票时，系统提供正常、稳定的服务。
代码地址：
大型高并发系统架构
高并发的系统架构都会采用分布式集群部署，服务上层有着层层负载均衡，并提供各种容灾手段（双火机房、节点容错、服务器灾备等）保证系统的高可用，流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。
下边是一个简单的示意图：
1、负载均衡简介
上图中描述了用户请求到服务器经历了三层的负载均衡，下边分别简单介绍一下这三种负载均衡。
①OSPF（开放式最短链路优先）是一个内部网关协议（InteriorGatewayProtocol，简称IGP）
OSPF通过路由器之间通告网络接口的状态来建立链路状态数据库，生成最短路径树，OSPF会自动计算路由接口上的Cost值，但也可以通过手工指定该接口的Cost值，手工指定的优先于自动计算的值。
OSPF计算的Cost，同样是和接口带宽成反比，带宽越高，Cost值越小。到达目标相同Cost值的路径，可以执行负载均衡，最多6条链路同时执行负载均衡。
②LVS（LinuxVirtualServer）
它是一种集群（Cluster）技术，采用IP负载均衡技术和基于内容请求分发技术。
调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。
③Nginx
想必大家都很熟悉了，是一款非常高性能的HTTP代理/反向代理服务器，服务开发中也经常使用它来做负载均衡。
Nginx实现负载均衡的方式主要有三种：
轮询
加权轮询
IPHash轮询
下面我们就针对Nginx的加权轮询做专门的配置和测试。
2、Nginx加权轮询的演示
Nginx实现负载均衡通过Upstream模块实现，其中加权轮询的配置是可以给相关的服务加上一个权重值，配置的时候可能根据服务器的性能、负载能力设置相应的负载。
下面是一个加权轮询负载的配置，我将在本地的监听3001-3004端口，分别配置1，2，3，4的权重：
/sec](mean)
Timeperrequest:23.387[ms](mean)
Timeperrequest:0.234[ms](mean,acrossallconcurrentrequests)
Transferrate:572.08[Kbytes/sec]received
ConnectionTimes(ms)
minmean[+/-sd]medianmax
Connect:0814.76223
Processing:21517.611232
Waiting:11113.58225
Total:72322.818239
Percentageoftherequestsservedwithinacertaintime(ms)
50%18
66%24
75%26
80%28
90%33
95%39
98%45
99%54
100%239(longestrequest)
根据指标显示，我单机每秒就能处理4000+的请求，正常服务器都是多核配置，处理1W+的请求根本没有问题。
而且查看日志发现整个服务过程中，请求都很正常，流量均匀，Redis也很正常：
//
result:1,localSales:145
result:1,localSales:146
result:1,localSales:147
result:1,localSales:148
result:1,localSales:149
result:1,localSales:150
result:0,localSales:151
result:0,localSales:152
result:0,localSales:153
result:0,localSales:154
result:0,localSales:156
总结回顾
总体来说，秒杀系统是非常复杂的。我们这里只是简单介绍模拟了一下单机如何优化到高性能，集群如何避免单点故障，保证订单不超卖、不少卖的一些策略。
完整的订单系统还有订单进度的查看，每台服务器上都有一个任务，定时的从总库存同步余票和库存信息展示给用户，还有用户在订单有效期内不支付，释放订单，补充到库存等等。
我们实现了高并发抢票的核心逻辑，可以说系统设计的非常的巧妙，巧妙的避开了对DB数据库IO的操作。
对Redis网络IO的高并发请求，几乎所有的计算都是在内存中完成的，而且有效的保证了不超卖、不少卖，还能够容忍部分机器的宕机。
我觉得其中有两点特别值得学习总结：
①负载均衡，分而治之
通过负载均衡，将不同的流量划分到不同的机器上，每台机器处理好自己的请求，将自己的性能发挥到极致。
这样系统的整体也就能承受极高的并发了，就像工作的一个团队，每个人都将自己的价值发挥到了极致，团队成长自然是很大的。
②合理的使用并发和异步
自Epoll网络架构模型解决了c10k问题以来，异步越来越被服务端开发人员所接受，能够用异步来做的工作，就用异步来做，在功能拆解上能达到意想不到的效果。
这点在Nginx、、Redis上都能体现，他们处理网络请求使用的Epoll模型，用实践告诉了我们单线程依然可以发挥强大的威力。
服务器已经进入了多核时代，Go语言这种天生为并发而生的语言，完美的发挥了服务器多核优势，很多可以并发处理的任务都可以使用并发来解决，比如Go处理HTTP请求时每个请求都会在一个Goroutine中执行。
总之，怎样合理的压榨CPU，让其发挥出应有的价值，是我们一直需要探索学习的方向。
原文：
代码地址：
声明：本文经作者授权转载，如需转载请联系原作者。
【】
