高铁12306的编程架构到底有多牛逼？

　　大家好，我是柠檬哥，专注编程知识分享。
　　欢迎关注程序员柠檬橙，编程路上不迷路，私信发送以下关键字获取编程资源：
　　发送1024打包下载10个G编程资源学习资料
　　发送001获取阿里大神LeetCode刷题笔记
　　发送002获取获取谷歌公司编程代码规范
　　发送003获取10个精美简历模板PDF和Word版
　　发送004获取100道精选C面试题和答案word版
　　发送005获取获取谷歌LeetCode算法笔记
　　最近看到一篇关于12306架构优化和演进的文章，介绍了12306是如何在全国人民的压测中不断进化的：
　　要知道12306网站仅在2015年春运高峰日处理了超过180亿次车票查询服务，平均TPS超过30万次s。
　　另外12306系统的复杂之处就在于，它的SKU（即StockkeepingUnit，库存保有单位）并不像一般电商网站那样，可以通过区别货品有和没有来简单计算，而是需要结合每条线路的不同区间来做复杂运算，并且，12306的SKU还是时刻动态变化着的。
　　12306抢票，极限并发带来的思考
　　虽然现在大多数情况下都能订到票，但是放票瞬间即无票的场景，相信大家都深有体会。
　　尤其是春节期间，大家不仅使用12306，还会考虑智行和其他的抢票软件，全国上下几亿人在这段时间都在抢票。
　　12306服务承受着这个世界上任何秒杀系统都无法超越的QPS，上百万的并发再正常不过了！
　　笔者专门研究了一下12306的服务端架构，学习到了其系统设计上很多亮点，在这里和大家分享一下并模拟一个例子：如何在100万人同时抢1万张火车票时，系统提供正常、稳定的服务
　　高并发的系统架构都会采用分布式集群部署，服务上层有着层层负载均衡，并提供各种容灾手段（双火机房、节点容错、服务器灾备等）保证系统的高可用，流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。
　　下边是一个简单的示意图：
　　负载均衡简介
　　上图中描述了用户请求到服务器经历了三层的负载均衡，下边分别简单介绍一下这三种负载均衡。
　　OSPF（开放式最短链路优先）是一个内部网关协议（InteriorGatewayProtocol，简称IGP）
　　OSPF通过路由器之间通告网络接口的状态来建立链路状态数据库，生成最短路径树，OSPF会自动计算路由接口上的Cost值，但也可以通过手工指定该接口的Cost值，手工指定的优先于自动计算机值。
　　OSPF计算的Cost，同样是和接口带宽成反比，带宽越高，Cost值越小。到达目标相同Cost值的路径，可以执行负载均衡，最多6条链路同时执行负载均衡。
　　LVS（LinuxVirtualServer）
　　它是一种集群（Cluster）技术，采用IP负载均衡技术和基于内容请求分发技术。
　　调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。
　　Nginx
　　想必大家都很熟悉了，是一款非常高性能的HTTP代理反向代理服务器，服务开发中也经常使用它来做负载均衡。
　　Nginx实现负载均衡的方式主要有三种：轮询加权轮询IPHash轮询
　　下面我们就针对Nginx的加权轮询做专门的配置和测试。Nginx加权轮询的演示
　　Nginx实现负载均衡通过Upstream模块实现，其中加权轮询的配置是可以给相关的服务加上一个权重值，配置的时候可能根据服务器的性能、负载能力设置相应的负载。
　　下面是一个加权轮询负载的配置，我将在本地的监听30013004端口，分别配置1，2，3，4的权重：配置负载均衡upstreamloadrule｛server127。0。0。1：3001weight1；server127。0。0。1：3002weight2；server127。0。0。1：3003weight3；server127。0。0。1：3004weight4；｝。。。server｛listen80；servernameloadbalance。comwww。loadbalance。location｛proxypasshttp：｝
　　我在本地etchosts目录下配置了www。loadbalance。com的虚拟域名地址。
　　接下来使用Go语言开启四个HTTP端口监听服务，下面是监听在3001端口的Go程序，其他几个只需要修改端口即可：packagemainimport（nethttposstrings）funcmain（）｛http。HandleFunc（buyticket，handleReq）http。ListenAndServe（：3001，nil）｝处理请求函数，根据请求将响应结果信息写入ahrefhttps：www。bs178。comrizhitargetblankclassinfotextkey日志afunchandleReq（whttp。ResponseWriter，rhttp。Request）｛failedMsg：handleinport：writeLog（failedMsg，。stat。log）｝写入ahrefhttps：www。bs178。comrizhitargetblankclassinfotextkey日志afuncwriteLog（msgstring，logPathstring）｛fd，：os。OpenFile（logPath，os。ORDWRos。OCREATEos。OAPPEND，0644）deferfd。Close（）content：strings。Join（〔〕string｛msg，r｝，3001）buf：〔〕byte（content）fd。Write（buf）｝
　　我将请求的端口日志信息写到了。stat。log文件当中，然后使用AB压测工具做压测：abn1000c100http：www。loadbalance。combuyticket
　　统计日志中的结果，30013004端口分别得到了100、200、300、400的请求量。
　　这和我在Nginx中配置的权重占比很好地吻合在了一起，并且负载后的流量非常的均匀、随机。
　　具体的实现大家可以参考Nginx的Upsteam模块实现源码，这里推荐一篇文章《Nginx中Upstream机制的负载均衡》：https：www。kancloud。cndigestunderstandingnginx202607秒杀抢购系统选型
　　回到我们最初提到的问题中来：火车票秒杀系统如何在高并发情况下提供正常、稳定的服务呢？
　　从上面的介绍我们知道用户秒杀流量通过层层的负载均衡，均匀到了不同的服务器上，即使如此，集群中的单机所承受的QPS也是非常高的。如何将单机性能优化到极致呢？
　　要解决这个问题，我们就要想明白一件事：通常订票系统要处理生成订单、减扣库存、用户支付这三个基本的阶段。
　　我们系统要做的事情是要保证火车票订单不超卖、不少卖，每张售卖的车票都必须支付才有效，还要保证系统承受极高的并发。
　　这三个阶段的先后顺序该怎么分配才更加合理呢？我们来分析一下：下单减库存
　　当用户并发请求到达服务端时，首先创建订单，然后扣除库存，等待用户支付。
　　这种顺序是我们一般人首先会想到的解决方案，这种情况下也能保证订单不会超卖，因为创建订单之后就会减库存，这是一个原子操作。
　　但是这样也会产生一些问题：在极限并发情况下，任何一个内存操作的细节都至关影响性能，尤其像创建订单这种逻辑，一般都需要存储到磁盘数据库的，对数据库的压力是可想而知的。如果用户存在恶意下单的情况，只下单不支付这样库存就会变少，会少卖很多订单，虽然服务端可以限制IP和用户的购买订单数量，这也不算是一个好方法。支付减库存
　　如果等待用户支付了订单在减库存，第一感觉就是不会少卖。但是这是并发架构的大忌，因为在极限并发情况下，用户可能会创建很多订单。
　　当库存减为零的时候很多用户发现抢到的订单支付不了了，这也就是所谓的超卖。也不能避免并发操作数据库磁盘IO。预扣库存
　　从上边两种方案的考虑，我们可以得出结论：只要创建订单，就要频繁操作数据库IO。
　　那么有没有一种不需要直接操作数据库IO的方案呢，这就是预扣库存。先扣除了库存，保证不超卖，然后异步生成用户订单，这样响应给用户的速度就会快很多；那么怎么保证不少卖呢？用户拿到了订单，不支付怎么办？
　　我们都知道现在订单都有有效期，比如说用户五分钟内不支付，订单就失效了，订单一旦失效，就会加入新的库存，这也是现在很多网上零售企业保证商品不少卖采用的方案。
　　订单的生成是异步的，一般都会放到MQ、Kafka这样的即时消费队列中处理，订单量比较少的情况下，生成订单非常快，用户几乎不用排队。扣库存的艺术
　　从上面的分析可知，显然预扣库存的方案最合理。我们进一步分析扣库存的细节，这里还有很大的优化空间，库存存在哪里？怎样保证高并发下，正确的扣库存，还能快速的响应用户请求？
　　在单机低并发情况下，我们实现扣库存通常是这样的：
　　为了保证扣库存和生成订单的原子性，需要采用事务处理，然后取库存判断、减库存，最后提交事务，整个流程有很多IO，对数据库的操作又是阻塞的。
　　这种方式根本不适合高并发的秒杀系统。接下来我们对单机扣库存的方案做优化：本地扣库存。
　　我们把一定的库存量分配到本地机器，直接在内存中减库存，然后按照之前的逻辑异步创建订单。
　　改进过之后的单机系统是这样的：
　　这样就避免了对数据库频繁的IO操作，只在内存中做运算，极大的提高了单机抗并发的能力。
　　但是百万的用户请求量单机是无论如何也抗不住的，虽然Nginx处理网络请求使用Epoll模型，c10k的问题在业界早已得到了解决。
　　但是Linux系统下，一切资源皆文件，网络请求也是这样，大量的文件描述符会使操作系统瞬间失去响应。
　　上面我们提到了Nginx的加权均衡策略，我们不妨假设将100W的用户请求量平均均衡到100台服务器上，这样单机所承受的并发量就小了很多。
　　然后我们每台机器本地库存100张火车票，100台服务器上的总库存还是1万，这样保证了库存订单不超卖，下面是我们描述的集群架构：
　　问题接踵而至，在高并发情况下，现在我们还无法保证系统的高可用，假如这100台服务器上有两三台机器因为扛不住并发的流量或者其他的原因宕机了。那么这些服务器上的订单就卖不出去了，这就造成了订单的少卖。
　　要解决这个问题，我们需要对总订单量做统一的管理，这就是接下来的容错方案。服务器不仅要在本地减库存，另外要远程统一减库存。
　　有了远程统一减库存的操作，我们就可以根据机器负载情况，为每台机器分配一些多余的Buffer库存用来防止机器中有机器宕机的情况。
　　我们结合下面架构图具体分析一下：
　　我们采用Redis存储统一库存，因为Redis的性能非常高，号称单机QPS能抗10W的并发。
　　在本地减库存以后，如果本地有订单，我们再去请求Redis远程减库存，本地减库存和远程减库存都成功了，才返回给用户抢票成功的提示，这样也能有效的保证订单不会超卖。
　　当机器中有机器宕机时，因为每个机器上有预留的Buffer余票，所以宕机机器上的余票依然能够在其他机器上得到弥补，保证了不少卖。
　　Buffer余票设置多少合适呢，理论上Buffer设置的越多，系统容忍宕机的机器数量就越多，但是Buffer设置的太大也会对Redis造成一定的影响。
　　虽然Redis内存数据库抗并发能力非常高，请求依然会走一次网络IO，其实抢票过程中对Redis的请求次数是本地库存和Buffer库存的总量。
　　因为当本地库存不足时，系统直接返回用户已售罄的信息提示，就不会再走统一扣库存的逻辑。
　　这在一定程度上也避免了巨大的网络请求量把Redis压跨，所以Buffer值设置多少，需要架构师对系统的负载能力做认真的考量。代码演示
　　Go语言原生为并发设计，我采用Go语言给大家演示一下单机抢票的具体流程。初始化工作
　　Go包中的Init函数先于Main函数执行，在这个阶段主要做一些准备性工作。
　　我们系统需要做的准备工作有：初始化本地库存、初始化远程Redis存储统一库存的Hash键值、初始化Redis连接池。
　　另外还需要初始化一个大小为1的Int类型Chan，目的是实现分布式锁的功能。
　　也可以直接使用读写锁或者使用Redis等其他的方式避免资源竞争，但使用Channel更加高效，这就是Go语言的哲学：不要通过共享内存来通信，而要通过通信来共享内存。
　　Redis库使用的是Redigo，下面是代码实现：。。。localSpike包结构体定义packagelocalSpiketypeLocalSpikestruct｛LocalInStockint64LocalSalesVolumeint64｝。。。remoteSpike对hash结构的定义和redis连接池packageremoteSpike远程订单存储健值typeRemoteSpikeKeysstruct｛SpikeOrderHashKeystringredis中秒杀订单hash结构keyTotalInventoryKeystringhash结构中总订单库存keyQuantityOfOrderKeystringhash结构中已有订单数量key｝初始化redis连接池funcNewPool（）redis。Pool｛returnredis。Pool｛MaxIdle：10000，MaxActive：12000，maxnumberofconnectionsDial：func（）（redis。Conn，error）｛c，err：redis。Dial（tcp，：6379）iferr！nil｛panic（err。Error（））｝returnc，err｝，｝｝。。。funcinit（）｛localSpikelocalSpike2。LocalSpike｛LocalInStock：150，LocalSalesVolume：0，｝remoteSpikeremoteSpike2。RemoteSpikeKeys｛SpikeOrderHashKey：tickethashkey，TotalInventoryKey：tickettotalnums，QuantityOfOrderKey：ticketsoldnums，｝redisPoolremoteSpike2。NewPool（）donemake（chanint，1）done1｝本地扣库存和统一扣库存
　　本地扣库存逻辑非常简单，用户请求过来，添加销量，然后对比销量是否大于本地库存，返回Bool值：packagelocalSpike本地扣库存，返回bool值func（spikeLocalSpike）LocalDeductionStock（）bool｛spike。LocalSalesVolumespike。LocalSalesVolume1returnspike。LocalSalesVolumespike。LocalInStock｝
　　注意这里对共享数据LocalSalesVolume的操作是要使用锁来实现的，但是因为本地扣库存和统一扣库存是一个原子性操作，所以在最上层使用Channel来实现，这块后边会讲。
　　统一扣库存操作Redis，因为Redis是单线程的，而我们要实现从中取数据，写数据并计算一些列步骤，我们要配合Lua脚本打包命令，保证操作的原子性：packageremoteSpike。。。。。。constLuaScriptlocalticketkeyKEYS〔1〕localtickettotalkeyARGV〔1〕localticketsoldkeyARGV〔2〕localtickettotalnumstonumber（redis。call（HGET，ticketkey，tickettotalkey））localticketsoldnumstonumber（redis。call（HGET，ticketkey，ticketsoldkey））查看是否还有余票，增加订单数量，返回结果值if（tickettotalnumsticketsoldnums）thenreturnredis。call（HINCRBY，ticketkey，ticketsoldkey，1）endreturn0远端统一扣库存func（RemoteSpikeKeysRemoteSpikeKeys）RemoteDeductionStock（connredis。Conn）bool｛lua：redis。NewScript（1，LuaScript）result，err：redis。Int（lua。Do（conn，RemoteSpikeKeys。SpikeOrderHashKey，RemoteSpikeKeys。TotalInventoryKey，RemoteSpikeKeys。QuantityOfOrderKey））iferr！nil｛returnfalse｝returnresult！0｝
　　我们使用Hash结构存储总库存和总销量的信息，用户请求过来时，判断总销量是否大于库存，然后返回相关的Bool值。
　　在启动服务之前，我们需要初始化Redis的初始库存信息：hmsettickethashkeytickettotalnums10000ticketsoldnums0响应用户信息
　　我们开启一个HTTP服务，监听在一个端口上：packagemain。。。funcmain（）｛http。HandleFunc（buyticket，handleReq）http。ListenAndServe（：3005，nil）｝
　　上面我们做完了所有的初始化工作，接下来handleReq的逻辑非常清晰，判断是否抢票成功，返回给用户信息就可以了。packagemain处理请求函数，根据请求将响应结果信息写入ahrefhttps：www。bs178。comrizhitargetblankclassinfotextkey日志afunchandleReq（whttp。ResponseWriter，rhttp。Request）｛redisConn：redisPool。Get（）LogMsg：done全局读写锁iflocalSpike。LocalDeductionStock（）remoteSpike。RemoteDeductionStock（redisConn）｛util。RespJson（w，1，抢票成功，nil）LogMsgLogMsgresult：1，localSales：strconv。FormatInt（localSpike。LocalSalesVolume，10）｝else｛util。RespJson（w，1，已售罄，nil）LogMsgLogMsgresult：0，localSales：strconv。FormatInt（localSpike。LocalSalesVolume，10）｝done1将抢票状态写入到log中writeLog（LogMsg，。stat。log）｝funcwriteLog（msgstring，logPathstring）｛fd，：os。OpenFile（logPath，os。ORDWRos。OCREATEos。OAPPEND，0644）deferfd。Close（）content：strings。Join（〔〕string｛msg，r｝，）buf：〔〕byte（content）fd。Write（buf）｝
　　前边提到我们扣库存时要考虑竞态条件，我们这里是使用Channel避免并发的读写，保证了请求的高效顺序执行。我们将接口的返回信息写入到了。stat。log文件方便做压测统计。单机服务压测
　　开启服务，我们使用AB压测工具进行测试：abn10000c100http：127。0。0。1：3005buyticket
　　下面是我本地低配Mac的压测信息：ThisisApacheBench，Version2。3revision：1826891Copyright1996AdamTwiss，ZeusTechnologyLtd，http：www。zeustech。netLicensedtoTheApacheSoftwareFoundation，http：www。apache。orgBenchmarking127。0。0。1（bepatient）Completed1000requestsCompleted2000requestsCompleted3000requestsCompleted4000requestsCompleted5000requestsCompleted6000requestsCompleted7000requestsCompleted8000requestsCompleted9000requestsCompleted10000requestsFinished10000requestsServerSoftware：ServerHostname：127。0。0。1ServerPort：3005DocumentPath：buyticketDocumentLength：29bytesConcurrencyLevel：100Timetakenfortests：2。339secondsCompleterequests：10000Failedrequests：0Totaltransferred：1370000bytesHTMLtransferred：290000bytesRequestspersecond：4275。96〔sec〕（mean）Timeperrequest：23。387〔ms〕（mean）Timeperrequest：0。234〔ms〕（mean，acrossallconcurrentrequests）Transferrate：572。08〔Kbytessec〕receivedConnectionTimes（ms）minmean〔sd〕medianmaxConnect：0814。76223Processing：21517。611232Waiting：11113。58225Total：72322。818239Percentageoftherequestsservedwithinacertaintime（ms）50186624752680289033953998459954100239（longestrequest）
　　根据指标显示，我单机每秒就能处理4000的请求，正常服务器都是多核配置，处理1W的请求根本没有问题。
　　而且查看日志发现整个服务过程中，请求都很正常，流量均匀，Redis也很正常：stat。log。。。result：1，localSales：145result：1，localSales：146result：1，localSales：147result：1，localSales：148result：1，localSales：149result：1，localSales：150result：0，localSales：151result：0，localSales：152result：0，localSales：153result：0，localSales：154result：0，localSales：156。。。总结回顾
　　总体来说，秒杀系统是非常复杂的。我们这里只是简单介绍模拟了一下单机如何优化到高性能，集群如何避免单点故障，保证订单不超卖、不少卖的一些策略
　　完整的订单系统还有订单进度的查看，每台服务器上都有一个任务，定时的从总库存同步余票和库存信息展示给用户，还有用户在订单有效期内不支付，释放订单，补充到库存等等。
　　我们实现了高并发抢票的核心逻辑，可以说系统设计的非常的巧妙，巧妙的避开了对DB数据库IO的操作。
　　对Redis网络IO的高并发请求，几乎所有的计算都是在内存中完成的，而且有效的保证了不超卖、不少卖，还能够容忍部分机器的宕机。
　　我觉得其中有两点特别值得学习总结：
　　负载均衡，分而治之
　　通过负载均衡，将不同的流量划分到不同的机器上，每台机器处理好自己的请求，将自己的性能发挥到极致。
　　这样系统的整体也就能承受极高的并发了，就像工作的一个团队，每个人都将自己的价值发挥到了极致，团队成长自然是很大的。
　　合理的使用并发和异步
　　自Epoll网络架构模型解决了c10k问题以来，异步越来越被服务端开发人员所接受，能够用异步来做的工作，就用异步来做，在功能拆解上能达到意想不到的效果。
　　这点在Nginx、Node。JS、Redis上都能体现，他们处理网络请求使用的Epoll模型，用实践告诉了我们单线程依然可以发挥强大的威力。
　　服务器已经进入了多核时代，Go语言这种天生为并发而生的语言，完美的发挥了服务器多核优势，很多可以并发处理的任务都可以使用并发来解决，比如Go处理HTTP请求时每个请求都会在一个Goroutine中执行。
　　总之，怎样合理地压榨CPU，让其发挥出应有的价值，是我们一直需要探索学习的方向。
　　作者：掘金绘你一世倾城来源：https：juejin。impost5d84e21f6fb9a06ac8248149
　　我是柠檬哥，专注编程知识分享。
　　欢迎关注程序员柠檬橙，编程路上不迷路，私信发送以下关键字获取编程资源：
　　发送1024打包下载10个G编程资源学习资料
　　发送001获取阿里大神LeetCode刷题笔记
　　发送002获取获取谷歌公司编程代码规范
　　发送003获取10个精美简历模板PDF和Word版
　　发送004获取100道精选C面试题和答案word版
　　发送005获取获取谷歌LeetCode算法笔记