作者｜方乐明
背景介绍
该系统由接入层、逻辑服务层、存储层与缓存构成。Proxy处理请求接入，Server承载主要的业务逻辑，Cache用于缓存库存数量、DB则用于数据持久化。
一个“秒杀”活动，对应DB中的一条库存记录。当用户进行商品“秒杀”时，系统的主要逻辑在于DB中库存的操作上。一般来说，对DB的操作流程有以下三步：
锁库存
插入“秒杀”记录
更新库存
其中，锁库存是为了避免并发请求时出现“超卖”情况。同时要求这三步操作需要在一个事务中完成（所谓的事务，是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行）。
“秒杀”系统的设计难点就在这个事务操作上。商品库存在DB中记为一行，大量用户同时“秒杀”同一商品时，第一个到达DB的请求锁住了这行库存记录。在第一个事务完成提交之前这个锁一直被第一个请求占用，后面的所有请求需要排队等待。同时参与“秒杀”的用户越多，并发进DB的请求越多，请求排队越严重。因此，并发请求抢锁，是典型的商品“秒杀”系统的设计难点。
解决高并发问题常用方案
普通商品“秒杀”活动系统，解决高并发问题的方案，大体有以下几种：
方案一，使用内存操作替代实时的DB事务操作。
如图2所示，将“实时扣库存”的行为上移到内存Cache中操作，内存Cache操作成功直接给Server返回成功，然后异步落DB持久化。
这个方案的优点是用内存操作替代磁盘操作，提高了并发性能。
方案二，使用乐观锁替代悲观锁。
所谓悲观锁，是关系数据库管理系统里的一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作对某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。对应于上文分析中的“并发请求抢锁”行为。
所谓乐观锁，它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。
商品“秒杀”系统中，乐观锁的具体应用方法，是在DB的“库存”记录中维护一个版本号。在更新“库存”的操作进行前，先去DB获取当前版本号。在更新库存的事务提交时，检查该版本号是否已被其他事务修改。如果版本没被修改，则提交事务，且版本号加1；如果版本号已经被其他事务修改，则回滚事务，并给上层报错。
这个方案解决了“并发请求抢锁”的问题，可以提高DB的并发处理能力。
如果拆红包采用乐观锁，那么在并发抢到相同版本号的拆红包请求中，只有一个能拆红包成功，其他的请求将事务回滚并返回失败，给用户报错，用户体验完全不可接受。
如果采用乐观锁，将会导致第一时间同时拆红包的用户有一部分直接返回失败，反而那些“手慢”的用户，有可能因为并发减小后拆红包成功，这会带来用户体验上的负面影响。
如果采用乐观锁的方式，会带来大数量的无效更新请求、事务回滚，给DB造成不必要的额外压力。
1.系统垂直SET化，分而治之。
红包系统根据这个红包ID，按一定的规则（如按ID尾号取模等），垂直上下切分。切分后，一个垂直链条上的逻辑Server服务器、DB统称为一个SET。
各个SET之间相互独立，互相解耦。并且同一个红包ID的所有请求，包括发红包、抢红包、拆红包、查详情详情等，垂直stick到同一个SET内处理，高度内聚。通过这样的方式，系统将所有红包请求这个巨大的洪流分散为多股小流，互不影响，分而治之，如下图所示。
这个方案解决了同时存在海量事务级操作的问题，将海量化为小量。
2.逻辑Server层将请求排队，解决DB并发问题。
红包系统是资金交易系统，DB操作的事务性无法避免，所以会存在“并发抢锁”问题。但是如果到达DB的事务操作（也即拆红包行为）不是并发的，而是串行的，就不会存在“并发抢锁”的问题了。
按这个思路，为了使拆红包的事务操作串行地进入DB，只需要将请求在Server层以FIFO（先进先出）的方式排队，就可以达到这个效果。从而问题就集中到Server的FIFO队列设计上。
首先，将同一个红包ID的所有请求stick到同一台Server。
上面SET化方案已经介绍，同个红包ID的所有请求，按红包ID stick到同个SET中。不过在同个SET中，会存在多台Server服务器同时连接同一台DB（基于容灾、性能考虑，需要多台Server互备、均衡压力）。
其次，设计单机请求排队方案。
将stick到同一台Server上的所有请求在被接收进程接收后，按红包ID进行排队。然后串行地进入worker进程（执行业务逻辑）进行处理，从而达到排队的效果，如下图所示。
最后，增加memcached控制并发。
为了防止Server中的请求队列过载导致队列被降级，从而所有请求拥进DB，系统增加了与Server服务器同机部署的memcached，用于控制拆同一个红包的请求并发数。
具体来说，利用memcached的CAS原子累增操作，控制同时进入DB执行拆红包事务的请求数，超过预先设定数值则直接拒绝服务。用于DB负载升高时的降级体验。
通过以上三个措施，系统有效地控制了DB的“并发抢锁”情况。
3.双维度库表设计，保障系统性能稳定
红包系统的分库表规则，初期是根据红包ID的hash值分为多库多表。随着红包数据量逐渐增大，单表数据量也逐渐增加。而DB的性能与单表数据量有一定相关性。当单表数据量达到一定程度时，DB性能会有大幅度下降，影响系统性能稳定性。采用冷热分离，将历史冷数据与当前热数据分开存储，可以解决这个问题。
具体来说，就是分库表规则像db_xx.t_y_dd设计，其中，xx/y是红包ID的hash值后三位，dd的取值范围在01~31，代表一个月天数最多31天。
通过这种双维度分库表方式，解决了DB单表数据量膨胀导致性能下降的问题，保障了系统性能的稳定性。同时，在热冷分离的问题上，又使得数据搬迁变得简单而优雅。
最后总结
今日荐号
StuQ
InfoQ推出的IT教育平台——斯达克学院（StuQ ） 为技术人提供系统实战课程 学习微服务，机器学习，iOS开发最潮流技术 回复“课程”获得热门课程介绍和优惠码
今日荐文
道哥：我回阿里的29个月和职业生涯的6点感想
閱讀更多 InfoQ 的文章
