微信红包-微信红包每秒收发76万个红包系统不会乱？.pdfVIP

【微信红包】微信红包每秒收发76 万个红包 系统不会乱？ 作者: 腾讯科技 来源: 腾讯科技 每年节假日，微信红包的收发数量都会暴涨，尤以除夕为最。如此大规模、高 峰值的业务需要，背后需要怎样的技术支撑？百亿级别的红包规模，如何保证 并发性能与资金安全？ 背景介绍 2017 年1 月28 日，正月初一，微信公布了用户在除夕当天收发微信红包的数 量——142 亿个，而其收发峰值也已达到76 万每秒。百亿级别的红包，如何保 障并发性能与资金安全？这给微信带来了超级挑战。面对挑战，微信红包在分析 了业界“秒杀”系统解决方案的基础上，采用了SET 化、请求排队串行化、双维 度分库表等设计，形成了独特的高并发、资金安全系统解决方案。实践证明，该 方案表现稳定，且实现了除夕夜系统零故障运行。 本文将为读者介绍百亿级别红包背后的系统高并发设计方案，包括微信红包的两 大业务特点、微信红包系统的技术难点、解决高并发问题通常使用的方案，以及 微信红包系统的高并发解决方案。 微信红包的两大业务特点 微信红包（尤其是发在微信群里的红包，即群红包）业务形态上很类似网上的普 通商品“秒杀”活动。 用户在微信群里发一个红包，等同于是普通商品“秒杀”活动的商品上架；微信群 里的所有用户抢红包的动作，等同于“秒杀”活动中的查询库存；用户抢到红包后 拆红包的动作，则对应“秒杀”活动中用户的“秒杀”动作。 不过除了上面的相同点之外，微信红包在业务形态上与普通商品“秒杀”活动相比， 还具备自身的特点： 首先，微信红包业务比普通商品“秒杀”有更海量的并发要求。 微信红包用户在微信群里发一个红包，等同于在网上发布一次商品“秒杀”活动。 假设同一时间有10 万个群里的用户同时在发红包，那就相当于同一时间有10 万个“秒杀”活动发布出去。10 万个微信群里的用户同时抢红包，将产生海量的并 发请求。 其次，微信红包业务要求更严格的安全级别。 微信红包业务本质上是资金交易。微信红包是微信支付的一个商户，提供资金流 转服务。 用户发红包时，相当于在微信红包这个商户上使用微信支付购买一笔“钱”，并且 收货地址是微信群。当用户支付成功后，红包“发货”到微信群里，群里的用户拆 开红包后，微信红包提供了将“钱”转入折红包用户微信零钱的服务。 资金交易业务比普通商品“秒杀”活动有更高的安全级别要求。普通的商品“秒杀” 商品由商户提供，库存是商户预设的，“秒杀”时可以允许存在“超卖” （即实际被 抢的商品数量比计划的库存多）、“少卖” （即实际被抢的商户数量比计划的库存 少）的情况。但是对于微信红包，用户发100 元的红包绝对不可以被拆出101 元；用户发100 元只被领取99 元时，剩下的1 元在24 小时过期后要精确地退 还给发红包用户，不能多也不能少。 以上是微信红包业务模型上的两大特点。 微信红包系统的技术难点 在介绍微信红包系统的技术难点之前，先介绍下简单的、典型的商品“秒杀”系统 的架构设计，如下图所示。 该系统由接入层、逻辑服务层、存储层与缓存构成。Proxy 处理请求接入，Server 承载主要的业务逻辑，Cache 用于缓存库存数量、DB 则用于数据持久化。 一个“秒杀”活动，对应DB 中的一条库存记录。当用户进行商品“秒杀”时，系统 的主要逻辑在于DB 中库存的操作上。一般来说，对DB 的操作流程有以下三步： 锁库存 插入“秒杀”记录 更新库存 其中，锁库存是为了避免并发请求时出现“超卖”情况。同时要求这三步操作需要 在一个事务中完成（所谓的事务，是指作为单个逻辑工作单元执行的一系列操作， 要么完全地执行，要么完全地不执行）。 “秒杀”系统的设计难点就在这个事务操作上。商品库存在DB 中记为一行，大量 用户同时“秒杀”同一商品时，第一个到达DB 的请求锁住了这行库存记录。在第 一个事务完成提交之前这个锁一直被第一个请求占用，后面的所有请求需要排队 等待。同时参与“秒杀”的用户越多，并发进DB 的请求越多，请求排队越严重。 因此，并发请求抢锁，是典型的商品“秒杀”系统的设计难点。 微信红包业务相比普通商品“秒杀”活动，具有海量并发、高安全级别要求的特点。 在微信红包系统的设计上，除了并发请求抢锁之外，还有以下两个突出难点： 首先，事务级操作量级大。上文介绍微信红包业务特点时提到，普遍情况下同时 会有数以万计的微信群在发红包。这个业务特点映射到微信红包系统设计上，就 是有数以万计的“并发请求抢锁”同时在进行。这使得DB 的压力比普通单个商品 “库存”被锁要大很多倍。 其次，事务性要