姜承尧破产码农IT界最会讲故事的男同学秒杀业务与难点

蒋承尧破产了

IT 行业最会讲故事的人

秒杀生意和困难

秒杀业务在各行各业都非常流行。在这里，我将互联网行业的闪电定义为在很短的时间内将产品分成多个部分进行购买的行为。微信抢红包、一元抢宝、双11购物促销等商家，本质上都可以算是秒杀商家。近期火爆红包的难点在于，这是处理金钱的秒杀场景，对事务的要求更高。秒杀业务的难点或痛点是同一时间段内有大量用户抢夺同款产品，造成服务器资源紧张。

在非秒杀的情况下，比如非大促销，用户的购买体验非常好。但是在秒杀场景下，这意味着多个用户同时在抢一个商品，也就是并发度很高，但是他们都集中在同一个商品上，导致本质上是串行操作。因为数据库层的本质是扣除同种产品的库存：

更糟糕的是电商系统 高并发库存系统设计，无论是 MySQL、Oracle 还是其他关系型数据库，这都会导致大量无意义的上下文切换，造成资源浪费。假设网易考拉上有10000个用户抢购了skuId=1的产品，那么每个时间点只有一个用户可以访问数据库操作，剩下的9999个用户需要等待，等待上一个之后用户完成操作，会唤醒9999用户，告诉他们现在可以进入，9999用户再次竞争，最后只有一个用户进入。这就是所谓的上下文切换。在秒杀场景下，这个成本会非常大。一个显着的表现就是CPU负载很高，而数据库请求的负载却很低。

秒杀常见的三种业务类型是：大促、抢微信/易信红包、一元赢宝。从并发量来看，大促>微信红包>1元赢宝。从可靠性要求来看：微信红包>一元赢宝>大促销。但无论是哪一种，原则上都不能超卖。一旦超卖，后果非常严重，尤其是微信红包业务。因此，我个人不推荐将秒杀业务放在缓存中的架构。这是赌RP，但后果可能很严重。

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

秒杀优化——限流

秒杀架构设计

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

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

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

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

数据存储层对于尖峰操作是持久的。为了优化秒杀，需要在架构设计中限制这三层的电流。

客户端层优化

客户端层的优化比较简单明了。原则上还是限制用户可以发送秒杀的次数，从而达到限流的效果。例如，启动尖峰后，按钮将变灰。此方法与短信验证码相同。短信发送后，一般需要120秒才能再次收到验证码。 120秒内发送的短信验证码显示为灰色。但是，这种方法对于高级程序员来说是无用的。因为Chrome电商系统 高并发库存系统设计，Firefox firebug按F12进入开发者模式就知道具体要求了。只要有心，模拟出类似的要求，抢几个月饼真的不难。

前端显示层优化

在大斌秒杀交易量访问场景下，前端展示也要做相应的页面级缓存，比如10秒内对同一用户进行页面缓存，对同一产品进行页面缓存。更重要的是，这可以大大提升用户体验。当然，现在浏览器本身也缓存了一部分数据，从而提升了用户的访问体验。当然，这有利也有弊。

服务接口调用优化

对于618、双11购物应用场景，仅优化前两块还远远不够。上面的优化其实可以作为常规的开发规范。但在大促期间，会有超大规模的访问请求，比如几万人同时抢小米手机，开盘前就能知道库存。因此，开发者可以通过消息队列或缓存CAS机制来限制对数据库层的实际访问次数。对于超出库存的，前端可以返回等待，周期性重试，直到库存达到0。

这里还有一个小问题，就是有的用户可能已经抢到了Lightning Deals的资格，但是最后没有完成支付。这在红包业务中是不存在的，但在电商行业是可能的。淘宝在高峰时段的处理方式是30分钟内没有完成支付就关闭订单，再次可见库存。而对于一元多宝这样的企业来说，30分钟似乎有点太长了。因此，如果付款失败，则没有重试订单的机制。

数据库层的优化

服务接口的调用可以起到限流的作用，但是对于同一种商品是限流的。促销期间访问数据库的请求不容忽视。如果数据库层有 2000 个用户同时进行秒杀操作，这个开销还是很大的。此时强烈建议用户开启数据库线程池功能（注意：不是连接池）。例如MySQL企业版的Thread Pool插件、社区版的Percona、InnoSQL数据库都支持线程池。

线程池的机制是每个用户的连接不一定会产生实际的硬连接，而是通过Pool机制分配的，即数据库中实际运行的线程数是固定的，减少了上下文切换时间，从而大大提高了数据库的性能。详情见我之前分享的文章：

数据库架构设计

数据库表结构设计与应用

表结构设计其实差不多，这里我们以微信红包业务为例：

分布式数据库架构

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

关于分布式数据库中间件的选择，网易十年积累的分布式中间件DDB已经商业化，网易全程提供技术支持。欢迎微信咨询：82946772。顺便说一句，想加入IMG微信群的同学也可以加我的微信获得微信群邀请。

长期坚持原著真的不容易，很多次都想放弃。坚持是一种信念，专注是一种态度！点赞是对作者最好的赞美