架构11 社交软件红包技术03

四、摇一摇红包系统组成

红包系统由三部分组成：
 

• 1）信息流；
• 2）业务流；
• 3）资金流。

这三部分在组织架构上由不同的后台团队完成：
 

• 1）信息流——微信后台；
• 2）业务流——微信支付后台；
• 3）资金流——财付通后台。

在平时，红包系统主要处理个人会话中以消息形式发出的红包，其中：
 

• 1）信息流主要包括用户操作背后的请求通信和红包消息在不同用户和群中的流转；
• 2）业务流是用户请求引发的包红包、抢红包和拆红包等的业务逻辑；
• 3）资金流则是红包背后的资金转账和入账等流程。

如上图所示，摇一摇红包系统架构包括三个方面：
 

• 1）资源预下载；
• 2）摇红包；
• 3）拆红包。

资源预下载：
在除夕，用户通过摇一摇参与活动，可以摇到红包或其他活动页，这些页面需要用到很多图片、视频或 H5 页面等资源。在活动期间，参与用户多，对资源的请求量很大，如果都通过实时在线访问，服务器的网络带宽会面临巨大压力，基本无法支撑；另外，资源的尺寸比较大，下载到手机需要较长时间，用户体验也会很差。因此，我们采用预先下载的方式，在活动开始前几天把资源推送给客户端，客户端在需要使用时直接从本地加载。

摇 / 拆红包：
除夕的摇一摇子系统是专门为活动定制的，按时间轴进行各项活动，这里边最重要、同时也是请求量最大的是摇红包。从需求上看，系统需要完成两个事：用户可以通过摇一摇抢到红包，红包金额可以入到用户的支付账户。在除夕，系统需要在很短时间内将几十亿个红包发放下去，对性能和可用性要求很高。考虑到涉及资金的业务逻辑比较复杂，还有很多数据库事务处理，耗时会比较长，于是我们将抢红包（信息流）和红包的账务逻辑（业务流和资金流）异步化。将前一部分处理流程尽可能设计得轻量，让用户可以很快抢到红包，然后再异步完成剩下的账务逻辑。

 

那么，抢红包阶段是怎样做到既轻量又可靠呢？

1）零 RPC 调用：

在微信后台系统中，一般情况下客户端发起的请求都是通过接入服务转发给具体的业务服务处理的，会产生 RPC 调用。但对于摇一摇请求，我们将摇一摇逻辑直接嵌入接入服务中，接入服务可以直接处理摇一摇请求，派发红包。

2）零数据库存储：

按一般的系统实现，用户看到的红包在系统中是数据库中的数据记录，抢红包就是找出可用的红包记录，将该记录标识为属于某个用户。在这种实现里，数据库是系统的瓶颈和主要成本开销。我们在这一过程完全不使用数据库，可以达到几个数量级的性能提升，同时可靠性有了更好的保障。
 

• 1）支付系统将所有需要下发的红包生成红包票据文件 ;
• 2）将红包票据文件拆分后放到每一个接入服务实例中；
• 3）接收到客户端发起摇一摇请求后，接入服务里的摇一摇逻辑拿出一个红包票据，在本地生成一个跟用户绑定的加密票据，下发给客户端；
• 4）客户端拿加密票据到后台拆红包，后台的红包简化服务通过本地计算即可验证红包，完成抢红包过程

3）异步化：

用户抢到红包后不会同步进行后续的账务处理，请求会被放入红包异步队列，再通过异步队列转给微信支付后台，由微信支付后台完成后续业务逻辑

方案一：预红包数据提供部署给微信的接入机和写入红包 DB，摇红包过程由红包接入机控制红包的发放，拆红包时修改红包 DB 中的红包数据；
方案二：预红包数据只提供部署给微信接入机，摇红包过程由红包接入机控制红包的发放，拆红包直接 Insert 到红包 DB。

第二个方案减少一次 DB 操作，如果是百亿量级的红包数据，可以极大减少数据导入、对账等活动准备时间，特别是方案需要变更时。