http://www.Sina.com/http://www.Sina.com/http://www.Sina.com /微信红包(特别是发给微信群的红色
用户在微信群上发红包，无异于普通商品“秒杀”活动的商品陈列； 微信群中所有用户抢红包的行为与“秒杀”事件中的库存查询相同； 用户收到红包后摘下红包的动作与“秒杀”事件中用户的“秒杀”动作相对应。
但除了上述相同之处外，微信红包在业务形态上与普通商品的“秒杀”活动相比，还具有自身的特点。
一：
微信红包用户在微信群上发红包，无异于在网上发布商品“秒杀”活动。 如果同一时间有10万人的群用户同时发送红包，那么同一时间就发布了10万人的“秒杀”活动。 当10万微信群用户同时抢红包时，会产生大量并发请求。
微信红包架构设计，高并发系统应用实战
微信红包业务本质上是资金交易。 微信红包是微信支付的商户，提供资金流动服务。
用户发送红包时，相当于在一家名为微信红包的店铺使用微信支付购买“钱”，收件方为微信群。 用户支付成功后，红包“发货”到微信群，群内用户拆开红包后，微信红包提供了“钱”折红包用户微信零钱的服务。
资金交易业务比普通商品的“秒杀”活动有更高的安全水平要求。 普通的“秒杀”商品由商户提供，库存由商户预置，“秒杀”允许“超售”、“少卖”、“实际被抢店铺数量少于计划库存”。 但是，对于微信红包，即使用户拿出100元的红包也绝对不要取下101元； 如果用户发100元只收99元，剩下的1元在24小时过期后，必须准确地退还给发红包的用户，不能多也不能少。
1. 微信红包架构两个“秒杀”事件对应于DB中的一个库存记录。 用户进行商品“秒杀”时，系统主要逻辑在于数据库库存的操作。 一般来说，DB的操作流程包括以下三个步骤。
a .锁定库存
b .插入“秒杀”记录
c .库存更新
“秒杀”系统的设计难点在于这个事务操作。 商品的库存在DB中作为一行进行记载，如果大量用户同时“秒杀”同一商品，则最初到达DB的请求锁定了该行的库存记录。 在第一个事务完成提交之前，此锁将被第一个请求占用，所有后续请求都必须排队等待。 同时参与“秒杀”的用户越多、并发访问数据库的请求越多，请求的行列就越严重。 因此，同时要求锁定是典型的商品“秒杀”系统的设计难点。
与普通商品“秒杀”活动相比，微信红包业务具有批量合并、安全水平要求高的特点。 在微信红包系统设计上，1.1 业务场景
首先，微信红包业务比普通商品“秒杀”有更海量的并发要求。在介绍上述微信红包业务特点时，一般同时有上万个微信群发送红包。 该业务的特点体现在微信红包系统设计上，就是数以万计的“同步加锁请求”同时出现。 这使得数据库的压力比普通单个商品的“库存”大很多倍。
其次，微信红包业务要求更严格的安全级别。微信红包本质上是一种资金交易系统，比普通商品的“秒杀”系统有更高的事务级要求。
1.2 业务逻辑
如图2所示，当将“实时调取库存”的动作移动到内存缓存中进行操作时，内存缓存的操作成功，直接向服务器返回成功，然后以异步方式进行数据库持久化。
除了并发请求抢锁之外，还有以下两个突出难点
但是，缺点也很明显，在存储器操作成功但DB的持续化失败的情况下，或者存储器缓存发生了故障的情况下，DB的持续化消除了数据，不适合微信红包这样的资金交易系统。
首先，事务级操作量极大
悲观锁是关系数据库管理系统中并发控制的方法。 防止一个事务更改数据以影响其他用户。 如果对包含某个事务执行的操作的行中的数据应用了锁定，则只有在事务解除锁定时，其他事务才能执行与该锁定冲突的操作。 对应于上述分析的“同时请求锁定”行为。
乐观锁定假定多个用户同时进行的事务处理互不影响，并且每个事务都能够在不锁定的情况下处理部分影响它们的数据。 在提交数据更新之前，每个事务都会在事务读取数据后检查其他事务是否更改了数据。 如果其他事务具有更新，则将回退正在提交的事务。
在商品“秒杀”系统中，乐观锁的具体应用方式是在数据库的“库存”记录中维护版本号。 在更新“库存”之前，去数据库获取当前的版本号。 检查在提交更新库存的事务处理时，版本号是否已由其他事务处理更改。 如果版本未更改，则会提交事务，并对版本号加1。 版本号已由其他事务更改
则回滚事务，并给上层报错。这个方案解决了“并发请求抢锁”的问题，可以提高 DB 的并发处理能力。
但是如果应用于微信红包系统，则会存在下面三个问题：
如果拆红包采用乐观锁，那么在并发抢到相同版本号的拆红包请求中，只有一个能拆红包成功，其他的请求将事务回滚并返回失败，给用户报错，用户体验完全不可接受。
如果采用乐观锁，将会导致第一时间同时拆红包的用户有一部分直接返回失败，反而那些“手慢”的用户，有可能因为并发减小后拆红包成功，这会带来用户体验上的负面影响。
如果采用乐观锁的方式，会带来大数量的无效更新请求、事务回滚，给 DB 造成不必要的额外压力。
基于以上原因，微信红包系统不能采用乐观锁的方式解决并发抢锁问题。
1.3 微信红包系统的高并发解决方案
综合上面的分析，微信红包系统针对相应的技术难点，采用了下面几个方案，解决高并发问题。
1. 系统垂直 SET 化，分而治之。
微信红包用户发一个红包时，微信红包系统生成一个 ID 作为这个红包的唯一标识。接下来这个红包的所有发红包、抢红包、拆红包、查询红包详情等操作，都根据这个 ID 关联。
红包系统根据这个红包 ID，按一定的规则（如按 ID 尾号取模等），垂直上下切分。切分后，一个垂直链条上的逻辑 Server 服务器、DB 统称为一个 SET。
各个 SET 之间相互独立，互相解耦。并且同一个红包 ID 的所有请求，包括发红包、抢红包、拆红包、查详情详情等，垂直 stick 到同一个 SET 内处理，高度内聚。通过这样的方式，系统将所有红包请求这个巨大的洪流分散为多股小流，互不影响，分而治之，如下图所示。
这个方案解决了同时存在海量事务级操作的问题，将海量化为小量。
2. 逻辑 Server 层将请求排队，解决 DB 并发问题。
红包系统是资金交易系统，DB 操作的事务性无法避免，所以会存在“并发抢锁”问题。但是如果到达 DB 的事务操作（也即拆红包行为）不是并发的，而是串行的，就不会存在“并发抢锁”的问题了。
按这个思路，为了使拆红包的事务操作串行地进入 DB，只需要将请求在 Server 层以 FIFO（先进先出）的方式排队，就可以达到这个效果。从而问题就集中到 Server 的 FIFO 队列设计上。
微信红包系统设计了分布式的、轻巧的、灵活的 FIFO 队列方案。其具体实现如下：
首先，将同一个红包 ID 的所有请求 stick 到同一台 Server。
上面 SET 化方案已经介绍，同个红包 ID 的所有请求，按红包 ID stick 到同个 SET 中。不过在同个 SET 中，会存在多台 Server 服务器同时连接同一台 DB（基于容灾、性能考虑，需要多台 Server 互备、均衡压力）。
为了使同一个红包 ID 的所有请求，stick 到同一台 Server 服务器上，在 SET 化的设计之外，微信红包系统添加了一层基于红包 ID hash 值的分流，如下图所示。
其次，设计单机请求排队方案。
将 stick 到同一台 Server 上的所有请求在被接收进程接收后，按红包 ID 进行排队。然后串行地进入 worker 进程（执行业务逻辑）进行处理，从而达到排队的效果，如下图所示。
最后，增加 memcached 控制并发。
为了防止 Server 中的请求队列过载导致队列被降级，从而所有请求拥进 DB，系统增加了与 Server 服务器同机部署的 memcached，用于控制拆同一个红包的请求并发数。
具体来说，利用 memcached 的 CAS 原子累增操作，控制同时进入 DB 执行拆红包事务的请求数，超过预先设定数值则直接拒绝服务。用于 DB 负载升高时的降级体验。
通过以上三个措施，系统有效地控制了 DB 的“并发抢锁”情况。
3. 双维度库表设计，保障系统性能稳定
红包系统的分库表规则，初期是根据红包 ID 的 hash 值分为多库多表。随着红包数据量逐渐增大，单表数据量也逐渐增加。而 DB 的性能与单表数据量有一定相关性。当单表数据量达到一定程度时，DB 性能会有大幅度下降，影响系统性能稳定性。采用冷热分离，将历史冷数据与当前热数据分开存储，可以解决这个问题。
处理微信红包数据的冷热分离时，系统在以红包 ID 维度分库表的基础上，增加了以循环天分表的维度，形成了双维度分库表的特色。
具体来说，就是分库表规则像 db_xx.t_y_dd 设计，其中，xx/y 是红包 ID 的 hash 值后三位，dd 的取值范围在 01~31，代表一个月天数最多 31 天。
通过这种双维度分库表方式，解决了 DB 单表数据量膨胀导致性能下降的问题，保障了系统性能的稳定性。同时，在热冷分离的问题上，又使得数据搬迁变得简单而优雅。
综上所述，微信红包系统在解决高并发问题上的设计，主要采用了 SET 化分治、请求排队、双维度分库表等方案，使得单组 DB 的并发性能提升了 8 倍左右，取得了很好的效果。
总结
微信红包系统是一个高并发的资金交易系统，最大的技术挑战是保障并发性能与资金安全。这种全新的技术挑战，传统的“秒杀”系统设计方案已不能完全解决。在分析了业界“秒杀”系统解决方案的基础上，微信红包采用了 SET 化、请求排队串行化、双维度分库表等设计，形成了独特的高并发、资金安全系统解决方案，并在平时节假日、2015 和 2016 春节实践中充分证明了可行性，取得了显著的效果。在刚刚过去的 2017 鸡年除夕夜，微信红包收发峰值达到 76 万每秒，收发微信红包 142 亿个，微信红包系统的表现稳定，实现了除夕夜系统零故障。
参考链接