高并发秒杀系统架构设计 · 抢购、微信红包、一元夺宝

秒杀业务与难点

秒杀业务在各业务中已然非常流行，这里我将互联网行业中的秒杀定义为：在非常短的时间内，将一件商品分成多份进行购买的行为。微信抢红包、、双11大促等业务本质上都可视作秒杀业务。而最近大热的抢红包的难度在于这是和钱打交道的秒杀场景，对于事务的要求性更高。秒杀业务的难点或者说痛点在于：同一件商品在同一时间段内有非常多的用户去进行抢夺，从而造成服务器资源的紧张。

 

非秒杀情况下，比如非大促的时候，用户购买的体验都是非常不错的。但是在秒杀场景下，这时意味着多个用户在同时抢一件商品，也就是并发很高，但集中在同一商品上，造成实质为串行操作。因为在数据库这层本质执行的是对同一件商品扣库存：

更糟糕的是，无论是MySQL、Oracle、还是其他关系型数据库，这会造成大量无意义的上下文切换，从而导致资源浪费。假设在网易考拉上有10000个用户对skuId=1的这件商品进行抢购，那么每个时间点仅有一个用户可以获得进入数据库操作的权限，剩下的9999个用户需要等待，待前面的用户完成操作后，会唤醒9999个用户，告诉他们现在可以进入了，9999个用户重新争夺一次，最终又仅有一个用户进入，这就是所谓的上下文切换。在秒杀场景下，这个代价将会非常大，一个显著的表现是CPU负载非常高，但数据库请求的负载却又非常低。

 

秒杀常见的三种业务类型为：大促抢购、抢微信/易信红包、一元夺宝。从并发量来看，大促抢购 > > 一元夺宝。从可靠性要求来看：微信红包 > 一元夺宝 > 大促抢购。但是无论是哪一种，原则上都不能超售，一旦超售后果非常严重，特别是微信红包业务。因此，我个人非常不建议将秒杀业务放在缓存中设计的架构，这是在赌RP，后果却可能非常严重。

秒杀业务的架构设计其实并不难，简单来说，就是不要让数据库处理承担这么多请求，减少无谓的上下文切换，业界一个比较学术的称谓叫做：限流。

秒杀优化——限流

秒杀架构设计

我倾向于将秒杀的系统架构设计分为以下几层：

• 客户端层：用户发起秒杀的浏览器、app或其他客户端；

• 前端Web展示层，负责接收用户请求，通常是Nginx或Apache等Web服务器；

• 服务接口调用层，接收到请求，调用相关服务进行秒杀操作；

• 数据存储层，对于秒杀操作进行持久化。要对秒杀进行优化，则对架构设计上需要对这三层进行限流。

 

客户端层优化

客户端层的优化比较简单明了，原则上来说依然是限制用户发秒秒杀的次数，从而做到限流的效果。比如在秒杀发起后，按钮变灰。这类做法和短信验证码一样，短信发送后一般需要等待120秒才能再次接收验证码，120秒内的发送短信验证码是灰色的。然而这种做法对于高阶程序员来说，就没啥用了。因为Chrome、Firefox firebug按F12进入开发者模式就能知道具体的请求。只要有心，模拟类似请求，抢几个月饼的难度真不大。

前端展示层优化

在大并的秒杀发量访问场景下，前端展示也要做好相应的页面级缓存，比如10秒内同一用户的页面缓存，同一商品的页面缓存。更重要的是，这样能大大提升用户的体验。当然，现在浏览器本身也会缓存一部分数据，从而提升用户的访问的体验。当然，这也是有利有弊。

服务接口调用优化

对于618、双11这样的全民抢购应用场景，做好前两块优化是远不够的。上述这些优化其实都可以作为例行的开发规范。但是在大促时间段，就是会有超大规模的访问请求，比如几万个人同时抢小米手机，而在开始前是可以知道库存的。因此，开发人员可以通过消息队列或者缓存CAS机制来限制访问到数据库层实际的数量。而对于超出库存的，则前端可以返回等待中，定期再进行重试，直到库存为0为止。

在这里还有个小问题，那就是有些用户可能已经抢到秒杀资格，但是最后没有完成付款。这在红包业务中不存在，但是在电商行业中却是有可能的。淘宝在高峰时间的处理方法是订单30分钟未完成支付即将关闭订单，库存重新可见。而对于像一元夺宝这样的业务，30分钟时间显得有些太长了。故一元夺宝支付失败并没有重试订单的机制。

数据库层的优化

服务接口的调用能起到限流的作用，但是是对同一件商品进行限流。大促期间访问到数据库这里的请求依然不容忽略。如果数据库这层有2000个用户在同时进行秒杀操作，那么这个开销依然非常巨大。这时强烈建议用户开启数据库线程池功能（注意：不是连接池），比如MySQL企业版的Thread Pool插件、社区版的Percona、数据库都支持线程池。

 

线程池的机制是每个用户的连接并不是一定会产生一个实际的硬连接，而是通过Pool机制从中进行分配，也就是实际在数据库内部运行的线程数是固定的，减小上下文切换的时间，从而大幅提升数据库的性能。具体可见我之前分享过的文章：

数据库架构设计

数据库表结构设计与应用

表结构设计其实大同小异，这里以微信红包业务作为案例分析：

 

 

分布式数据库架构

即使做了上述这么多秒杀优化，相信对于高峰期的微信抢红包业务来说也是无法承载的。记得有同学在IMG微信群中有说过（1年多前），微信红包是由70台服务器组成的分布式数据库集群。对于这样的分布式集群，开发人员可以选择红包Id作为均衡字段进行分库分表，通过分布式数据库的可扩展性提升整个集群的性能。需要特别注意的是，由于是分布式架构，建议将上述红包Id的数据类型更改为全局唯一的字符串类型，用户可以自己生成一个规则，或直接使用UUID这样的函数。