10亿红包从天而降揭秘微信摇一摇背后的技术细节
【编者按】与传统意义上的红包相比，近两年火起来的“红包”，似乎才是如今春节的一大重头戏。历经上千年时代传承与变迁，春节发红包早已成为历史沉淀的文化习俗，融入了民族的血脉。按照各家公布的数据，除夕全天微信用户红包总发送量达到80.8亿个，红包峰值收发量为40.9万个/秒。春晚直播期间讨论春晚的微博达到5191万条，网友互动量达到1.15亿，网友抢微博红包的总次数超过8亿次。
2016年春节的三波红包雨——摇红包已经过去一段时间，面对亿级的企业资金以及亿级的红包，回想这其中的过程并不简单，充满各种变数，稍有闪失就可能功亏一篑。让我们一起回顾一下这里的准备过程，看看技术上是如何为这只许成功不许失败的项目保驾护航的。
一．除夕活动红包系统
红包系统由三部分组成：信息流、业务流和资金流。这三部分在组织架构上由不同的后台团队完成：信息流——微信后台，业务流——微信支付后台，资金流——财付通后台。
在平时，红包系统主要处理个人会话中以消息形式发出的红包。其中，信息流主要包括用户操作背后的请求通信和红包消息在不同用户和群中的流转；业务流是用户请求引发的包红包、抢红包和拆红包等的业务逻辑；资金流则是红包背后的资金转账和入账等流程。
红包系统在除夕活动时和平时的实现不大一样。在除夕活动时，除了个人红包外，红包系统还要处理由后台通过摇一摇集中下发的大量企业红包。这里边信息流的实现变化较大。
接下来简单介绍一下2016年除夕活动时的红包系统架构，包括三个方面：资源预下载、摇红包、拆红包（见图1）。
图1
1．资源预下载
在除夕，用户通过摇一摇参与活动，可以摇到红包或其他活动页，这些页面需要用到很多图片、视频或H5页面等资源。在活动期间，参与用户多，对资源的请求量很大，如果都通过实时在线访问，服务器的网络带宽会面临巨大压力，基本无法支撑；另外，资源的尺寸比较大，下载到手机需要较长时间，用户体验也会很差。因此，我们采用预先下载的方式，在活动开始前几天把资源推送给客户端，客户端在需要使用时直接从本地加载。
2．摇/拆红包
除夕的摇一摇子系统是专门为活动定制的，按时间轴进行各项活动，这里边最重要、同时也是请求量最大的是摇红包。从需求上看，系统需要完成两个事：用户可以通过摇一摇抢到红包，红包金额可以入到用户的支付账户。在除夕，系统需要在很短时间内将几十亿个红包发放下去，对性能和可用性要求很高。考虑到涉及资金的业务逻辑比较复杂，还有很多数据库事务处理，耗时会比较长，于是我们将抢红包（信息流）和红包的账务逻辑（业务流和资金流）异步化。将前一部分处理流程尽可能设计得轻量，让用户可以很快抢到红包，然后再异步完成剩下的账务逻辑。
那么，抢红包阶段是怎样做到既轻量又可靠呢？
1．零RPC调用
在微信后台系统中，一般情况下客户端发起的请求都是通过接入服务转发给具体的业务服务处理的，会产生RPC调用。但对于摇一摇请求，我们将摇一摇逻辑直接嵌入接入服务中，接入服务可以直接处理摇一摇请求，派发红包。
2．零数据库存储
按一般的系统实现，用户看到的红包在系统中是数据库中的数据记录，抢红包就是找出可用的红包记录，将该记录标识为属于某个用户。在这种实现里，数据库是系统的瓶颈和主要成本开销。我们在这一过程完全不使用数据库，可以达到几个数量级的性能提升，同时可靠性有了更好的保障。
支付系统将所有需要下发的红包生成红包票据文件；
· 将红包票据文件拆分后放到每一个接入服务实例中；
· 接收到客户端发起摇一摇请求后，接入服务里的摇一摇逻辑拿出一个红包票据，在本地生成一个跟用户绑定的加密票据，下发给客户端；
· 客户端拿加密票据到后台拆红包，后台的红包简化服务通过本地计算即可验证红包，完成抢红包过程。
3．异步化
用户抢到红包后不会同步进行后续的账务处理，请求会被放入红包异步队列，再通过异步队列转给微信支付后台，由微信支付后台完成后续业务逻辑。