微信红包设计方案

前言

微信红包一经推出，春节期间微信用户红包总发送量达80.8亿，红包峰值40.9w/秒，在如此量级下，系统设计存在各类变数，稍有闪失会功亏一篑。

红包系统

红包系统有三部分组成：信息流，业务流，资金流。 对应的后台系统包括，微信后台，支付后台，财付通后台。

红包架构包括三方面：资源预下载，摇一摇，拆红包。

在摇一摇以前，会先将资源推送到本地客户端。

为处理高峰期的摇一摇和支付逻辑，避免复杂逻辑及事务处理耗时较长，将摇一摇和红包到帐按异步逻辑处理。 同时为下降抢红包后写DB的耗时，将红包信息票据进行加密放到客户端，经过本地计算完成抢红包过程。 后续的结算逻辑放入消息队列中，经过异步方式进入结算系统，完成后续工做。

大规模集群中保证数据一致性

为保证系统可用性，红包系统在多个独立数据中心进行部署，能够达到在任意一个园区机房故障后，对外提供服务。 多园区的关键是数据一致性，须要维护强一致性副本，这样能够无损提供服务。 微信采用Quorum算法，对数据有强一致保证的存储系统。三园区的强一致性保证采用可靠队列。

系统可用性

进行系统容量评估，结合业务设计合理配额方案及降级方案，尽量保证系统不过载。 若是出现过载，系统需具备自我保护能力，不扩散到其余服务，若是处理不过来，按请求优先级丢弃超载请求。 减小核心路径涉及的步骤和模块，集中力量保证关键路径可用性。 系统监控，对真实负载有所了解，创建核心指标观察，系统暂时不可用，经过重试自动解决。 在系统设计以前，评估系统2000w/s的qps峰值请求，系统实现上有必定预估量，评估值为2.5倍（5kw/s qps），大部分时间低于峰值，若是超过阈值，客户端及服务端进行流控降级。

• 方案一：预红包数据提供部署给微信的接入机和写入红包DB，摇红包过程由红包接入机控制红包的发放，拆红包时修改红包DB中的红包数据；
• 方案二：预红包数据只提供部署给微信接入机，摇红包过程由红包接入机控制红包的发放，拆红包直接Insert到红包DB。 第二个方案减小一次DB操做，若是是百亿量级的红包数据，能够极大减小数据导入、对帐等活动准备时间，特别是方案须要变动时。