抢红包系统设计

一、业务背景&挑战&目标

1.1.背景

每年节假日，微信红包的收发数量都会暴涨，尤以除夕为最。如此大规模、高峰值的业务需要，背后需要怎样的技术支撑？百亿级别的红包规模，如何保证并发性能与资金安全？

 1.2.红包业务面临的挑战

微信红包（尤其是发在微信群里的红包，即群红包），业务形态上很类似网上的普通商品“秒杀”活动。

就像下面这样：

• 1）用户在微信群里发一个红包，等同于是普通商品“秒杀”活动的商品上架；
• 2）微信群里的所有用户抢红包的动作，等同于“秒杀”活动中的查询库存；
• 3）用户抢到红包后拆红包的动作，则对应“秒杀”活动中用户的“秒杀”动作。

不过除了上面的相同点之外，微信红包在业务形态上与普通商品“秒杀”活动相比，还具备自身的特点。

首先：微信红包业务比普通商品“秒杀”有更海量的并发要求。

微信红包用户在微信群里发一个红包，等同于在网上发布一次商品“秒杀”活动。假设同一时间有 10 万个群里的用户同时在发红包，那就相当于同一时间有 10 万个“秒杀”活动发布出去。10 万个微信群里的用户同时抢红包，将产生海量的并发请求。

其次：微信红包业务要求更严格的安全级别。

微信红包业务本质上是资金交易。微信红包是微信支付的一个商户，提供资金流转服务。

用户发红包时，相当于在微信红包这个商户上使用微信支付购买一笔“钱”，并且收货地址是微信群。当用户支付成功后，红包“发货”到微信群里，群里的用户拆开红包后，微信红包提供了将“钱”转入折红包用户微信零钱的服务。

资金交易业务比普通商品“秒杀”活动有更高的安全级别要求。普通的商品“秒杀”商品由商户提供，库存是商户预设的，“秒杀”时可以允许存在“超卖”（即实际被抢的商品数量比计划的库存多）、“少卖”（即实际被抢的商户数量比计划的库存少）的情况。但是对于微信红包，用户发 100 元的红包绝对不可以被拆出 101 元；用户发 100 元只被领取 99 元时，剩下的 1 元在 24 小时过期后要精确地退还给发红包用户，不能多也不能少。

以上是微信红包业务模型上的两大特点。

 

二、抢红包需求分析

2.1.红包业务分析

 

红包业务主要分为以下两部分内容:

• 核心流程
  • 包红包:设置红包类型、金额、人数等红包基本信息
  • 发红包:生成发红包记录、生成并发送红包消息
  • 抢红包:查询红包状态、库存、扣减库存
  • 拆红包:生成红包金额、生成拆红包记录、修改红包剩余金额、发放奖励(现金或者其它奖励)
• 记录和状态展示
  • 红包消息状态变更
  • 用户发红包记录
  • 用户抢红包记录

 

2.2.核心业务流程说明

2.2.1.包红包、发红包流程

 

 

2.2.2.抢红包、拆红包流程

 

三、红包系统技术方案

3.1.技术难点

 

红包系统面临以下挑战:

• 高并发:在某一时刻,可能存在几十万个抢红包的行为.如2017 鸡年除夕，微信红包抢红包用户数高达 3.42 亿，收发峰值 76 万/秒，发红包 37.77 亿 个。
• 安全性要求:红包业务涉及资金交易，所以一定不能出现超卖、少卖的情况。
  • 超卖：发了 10 块钱，结果抢到了 11 块钱，多的钱只能系统补上，如此为爱发电应用估计早就下架了；
  • 少卖：发了 10 块钱，只抢了 9 块，多的钱得原封不动地退还用户，否则第二天就接到法院传单了。
• 严格事务:参与用户越多，并发 DB 请求越大，数据越容易出现事务问题，所以系统得做好事务一致性。

  这也是一般秒杀活动的难点所在，而且抢红包系统涉及金钱交易，所以事务级别要求更高，不能出现脏数据。　　

 

3.2.红包系统整体架构

 

3.3.红包信息查询

 

3.4.抢红包设计

 

 

3.5.拆红包设计