前言
微信红包一经推出，春节期间微信用户红包总发送量达80.8亿，红包峰值40.9w/秒，在如此量级下，系统设计存在各种变数，稍有闪失会功亏一篑。
红包系统
红包系统有三部分组成：信息流，业务流，资金流。 对应的后台系统包括，微信后台，支付后台，财付通后台。
红包架构包括三方面：资源预下载，摇一摇，拆红包。 
在摇一摇之前，会先将资源推送到本地客户端。
为处理高峰期的摇一摇和支付逻辑，避免复杂逻辑及事务处理耗时较长，将摇一摇和红包到账按异步逻辑处理。 同时为降低抢红包后写DB的耗时，将红包信息票据进行加密放到客户端，通过本地计算完成抢红包过程。 后续的结算逻辑放入消息队列中，通过异步方式进入结算系统，完成后续工作。
大规模集群中保证数据一致性
为保证系统可用性，红包系统在多个独立数据中心进行部署，可以达到在任意一个园区机房故障后，对外提供服务。 多园区的关键是数据一致性，需要维护强一致性副本，这样可以无损提供服务。 微信采用Quorum算法，对数据有强一致保证的存储系统。三园区的强一致性保证采用可靠队列。
系统可用性
进行系统容量评估，结合业务设计合理配额方案及降级方案，尽可能保证系统不过载。 如果出现过载，系统需具有自我保护能力，不扩散到其他服务，如果处理不过来，按请求优先级丢弃超载请求。 减少核心路径涉及的步骤和模块，集中力量保证关键路径可用性。 系统监控，对真实负载有所了解，建立核心指标观察，系统暂时不可用，通过重试自动解决。 在系统设计之前，评估系统2000w/s的qps峰值请求，系统实现上有一定预估量，评估值为2.5倍（5kw/s qps），大部分时间低于峰值，如果超过阈值，客户端及服务端进行流控降级。 
- 方案一：预红包数据提供部署给微信的接入机和写入红包DB，摇红包过程由红包接入机控制红包的发放，拆红包时修改红包DB中的红包数据；
- 方案二：预红包数据只提供部署给微信接入机，摇红包过程由红包接入机控制红包的发放，拆红包直接Insert到红包DB。 第二个方案减少一次DB操作，如果是百亿量级的红包数据，可以极大减少数据导入、对账等活动准备时间，特别是方案需要变更时。