每秒100万请求，“12306”的架构到底有多牛？

2021-02-22 分类：网站建设

前段时间，媒体公布“12306”成为全球大票务交易系统。

那些年熬夜刷的12306经过多年迭代，承受着这个世界上任何秒杀系统都无法超越的 QPS，上百万的并发再正常不过。那么，系统如何在 100 万人同时抢 1 万张火车票时，提供稳定的服务？

高并发的系统架构都会采用分布式集群部署，服务上层有着层层负载均衡，并提供各种容灾手段（双火机房、节点容错、服务器灾备等）保证系统的高可用，流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。

用户秒杀流量通过层层的负载均衡，均匀到了不同的服务器上，即使如此，集群中的单机所承受的 QPS 也是非常高的。如何将单机性能优化到极致呢？

通常订票系统要处理生成订单、减扣库存、用户支付这三个基本的阶段。

系统要做的事情是要保证火车票订单不超卖、不少卖，每张售卖的车票都必须支付才有效，还要保证系统承受极高的并发。

这三个阶段的先后顺序如何分配才合理？

下单减库存

每秒100万请求，“12306”的架构到底有多牛？

当用户并发请求到达服务端时，首先创建订单，然后扣除库存，等待用户支付。

这种顺序是一般人首先会想到的解决方案，这种情况下也能保证订单不会超卖，因为创建订单之后就会减库存，这是一个原子操作。

会产生一些问题：

支付减库存

每秒100万请求，“12306”的架构到底有多牛？

如果等待用户支付了订单在减库存，第一感觉就是不会少卖。但是这是并发架构的大忌，因为在极限并发情况下，用户可能会创建很多订单。

当库存减为零的时候很多用户发现抢到的订单支付不了了，这也就是所谓的“超卖”。也不能避免并发操作数据库磁盘 IO。

每秒100万请求，“12306”的架构到底有多牛？

从上边两种方案的考虑，我们可以得出结论：只要创建订单，就要频繁操作数据库 IO。

那么有没有一种不需要直接操作数据库 IO 的方案呢，这就是预扣库存。先扣除了库存，保证不超卖，然后异步生成用户订单，这样响应给用户的速度就会快很多；那么怎么保证不少卖呢？用户拿到了订单，不支付怎么办？

我们都知道现在订单都有有效期，比如说用户五分钟内不支付，订单就失效了，订单一旦失效，就会加入新的库存，这也是现在很多网上零售企业保证商品不少卖采用的方案。

订单的生成是异步的，一般都会放到 MQ、Kafka 这样的即时消费队列中处理，订单量比较少的情况下，生成订单非常快，用户几乎不用排队。

从上面的分析可知，显然预扣库存的方案最合理。我们进一步分析扣库存的细节，这里还有很大的优化空间，库存存在哪里？怎样保证高并发下，正确的扣库存，还能快速的响应用户请求？

在单机低并发情况下实现扣库存通常：

每秒100万请求，“12306”的架构到底有多牛？

为了保证扣库存和生成订单的原子性，需要采用事务处理，然后取库存判断、减库存，最后提交事务，整个流程有很多 IO，对数据库的操作又是阻塞的。

这种方式根本不适合高并发的秒杀系统。接下来我们对单机扣库存的方案做优化：本地扣库存。

我们把一定的库存量分配到本地机器，直接在内存中减库存，然后按照之前的逻辑异步创建订单。

改进过之后的单机系统是这样的：

每秒100万请求，“12306”的架构到底有多牛？

这样就避免了对数据库频繁的 IO 操作，只在内存中做运算，极大的提高了单机抗并发的能力。

但是百万的用户请求量单机是无论如何也抗不住的，虽然 Nginx 处理网络请求使用 Epoll 模型，c10k 的问题在业界早已得到了解决。

但是 Linux 系统下，一切资源皆文件，网络请求也是这样，大量的文件描述符会使操作系统瞬间失去响应。

上面我们提到了 Nginx 的加权均衡策略，不妨假设将 100W 的用户请求量平均均衡到 100 台服务器上，这样单机所承受的并发量就小了很多。

然后我们每台机器本地库存 100 张火车票，100 台服务器上的总库存还是 1 万，这样保证了库存订单不超卖，以下是集群架构：

每秒100万请求，“12306”的架构到底有多牛？

问题接踵而至，在高并发情况下，现在还无法保证系统的高可用，假如这 100 台服务器上有两三台机器因为扛不住并发的流量或者其他的原因宕机了。那么这些服务器上的订单就卖不出去了，这就造成了订单的少卖。

要解决这个问题，我们需要对总订单量做统一的管理，这就是接下来的容错方案。服务器不仅要在本地减库存，另外要远程统一减库存。

有了远程统一减库存的操作，我们就可以根据机器负载情况，为每台机器分配一些多余的“Buffer 库存”用来防止机器中有机器宕机的情况。

结合下面架构图具体分析：

每秒100万请求，“12306”的架构到底有多牛？

采用 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，代码实现：

本地扣库存和统一扣库存

本地扣库存逻辑非常简单，用户请求过来，添加销量，然后对比销量是否大于本地库存，返回 Bool 值：

注意这里对共享数据 LocalSalesVolume 的操作是要使用锁来实现的，但是因为本地扣库存和统一扣库存是一个原子性操作，所以在最上层使用 Channel 来实现，这块后边会讲。

统一扣库存操作 Redis，因为 Redis 是单线程的，而我们要实现从中取数据，写数据并计算一些列步骤，我们要配合 Lua 脚本打包命令，保证操作的原子性：

使用 Hash 结构存储总库存和总销量的信息，用户请求过来时，判断总销量是否大于库存，然后返回相关的 Bool 值。

在启动服务之前，需要初始化 Redis 的初始库存信息：

响应用户信息

我们开启一个 HTTP 服务，监听在一个端口上：

做完了所有的初始化工作，接下来 handleReq 的逻辑非常清晰，判断是否抢票成功，返回给用户信息就可以了。

前面提到扣库存时要考虑竞态条件，这里使用 Channel 避免并发的读写，保证了请求的高效顺序执行。我们将接口的返回信息写入到了 ./stat.log 文件方便做压测统计。

单机服务测压

开启服务，我们使用 AB 压测工具进行测试：

本地低配 Mac 的压测信息：

根据指标显示，单机每秒就能处理 4000+ 的请求，正常服务器都是多核配置，处理 1W+ 的请求根本没有问题。

而且查看日志发现整个服务过程中，请求都很正常，流量均匀，Redis 也很正常：

秒杀系统是非常复杂的，本文仅简单介绍模拟了一下单机如何优化到高性能，集群如何避免单点故障，保证订单不超卖、不少卖的一些策略。

还涉及完整的订单系统还有订单进度的查看，定时的从总库存同步余票和库存信息展示给用户，以及用户在订单有效期内不支付，释放订单，补充到库存等等。

总之，负载均衡，分而治之，每台机器处理好自己的请求，将自己的性能发挥到极致。合理的使用并发和异步，合理的压榨 CPU，让其发挥出应有的价值。

当前标题：每秒100万请求，“12306”的架构到底有多牛？
文章地址：/news23/102273.html

成都网站建设公司_创新互联，为您提供定制网站、微信公众号、网站建设、App开发、手机网站建设、网站内链

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容