异地架构、cache系统优化、拆红包并发策略优化（高并发+红包算法）、存储优化一系列措施
一、架构( 南北分布 )
1、订单层南北独立体系，数据不同步
用户就近接入，请求发红包时分配订单南北，并在单号打上南北标识。抢红包、拆红包、查红包详情列表时，接入层根据红包单号上的南北标识将流量分别引到南北系统闭环。根据发红包用户和抢红包用户的所属地不同：
1) 深圳用户发红包，深圳用户抢：订单落在深圳，深圳用户抢红包时不需要跨城，在深圳完成闭环。
2) 深圳用户发红包，上海用户抢：订单落在深圳，上海用户抢红包，在上海接入后通过专线跨城到深圳，最后在深圳闭环完成抢红包。上海同理.
分摊流量，降低系统风险。
2、用户数据写多读少，全量存深圳，异步队列写入，查时一边跨城
用户数据的查询入口，在微信钱包中，隐藏的很深。这决定了用户数据的访问量不会太大，而且也被视为可旁路的非关键信息，实时性要求不高。因此，只需要在发红包、拆红包时，从订单纬度拆分出用户数据写入请求，由MQ异步写入深圳。后台将订单与用户进行定时对账保证数据完整性即可。（抢不是查嘛？）
3、支持南北流量灵活调控
订单落地到深圳还是上海，是可以灵活分配的。例如，可以在接入层中，实现让所有红包请求，都落地到深圳（无论用户从上海接入，还是深圳接入），这样上海的红包业务系统将不会有请求量。提升了容灾能力。可根据南北请求量的实时监控，做出对应的调配。
4、DB故障时流量转移能力
基于南北流量的调控能力，当发现DB故障时，可将红包业务流量调到另外一边，实现DB故障的容灾。
二、cache系统优化
（1）预订单：支付前订单落cache，同时利用cache的原子incr操作顺序生成红包订单号。
优点是cache的轻量操作，以及减少DB废单。在用户请求发红包与真正支付之间，存在一定的转化率，部分用户请求发红包后，并不会真正去付款。
（2）拆红包入账异步化
信息流与资金流分离。拆红包时，DB中记下拆红包凭证，然后异步队列请求入账。入账失败通过补偿队列补偿，最终通过红包凭证与用户账户入账流水对账，保证最终一致性。如下图所示：
这个架构设计，理论基础是快慢分离。红包的入账是一个分布事务，属于慢接口。而拆红包凭证落地则速度快。实际应用场景中，用户抢完红包，只关心详情列表中谁是“最佳手气”，很少关心抢到的零是否已经到账。因为只需要展示用户的拆红包凭证即可。
发拆落地，其他操作双层cache
1、Cache住所有查询，两层cache
除了使用ckv做全量缓存，还在数据访问层dao中增加本机内存cache做二级缓存，cache住所有读请求。
查询失败或者查询不存在时，降级内存cache；内存cache查询失败或记录不存在时降级DB。
DB本身不做读写分离。
2、DB写同步cache，容忍少量不一致
DB写操作完成后，dao中同步内存cache，业务服务层同步ckv，失败由异步队列补偿，定时的ckv与DB备机对账，保证最终数据一致。
三、高并发
1、请求按红包订单路由，逻辑块垂直sticky，事务隔离
按红包订单划分逻辑单元，单元内业务闭环。服务rpc调用时，使用红包订单号的hash值为key寻找下一跳地址。对同一个红包的所有拆请求、查询请求，都路由到同一台逻辑机器、同一台DB中处理。
2、Dao搭建本机Memcache内存cache，控制同一红包并发个数
在DB的接入机dao中，搭建本机内存cache。以红包订单号为key，对同一个红包的拆请求做原子计数，控制同一时刻能进DB中拆红包的并发请求数。
这个策略的实施，依赖于请求路由按红包订单hash值走，确保同一红包的所有请求路由到同一逻辑层机器。
3、多层级并发量控制
1) 发红包控制
发红包是业务流程的入口，控制了这里的并发量，代表着控制了红包业务整体的并发量。在发红包的业务链路里，做了多层的流量控制，确保产生的有效红包量级在可控范围。
2) 抢红包控制
微信红包领取时分为两个步骤，抢和拆。抢红包这个动作本身就有控制拆并发的作用。因为抢红包时，只需要查cache中的数据，不需要请求DB。对于红包已经领完、用户已经领过、红包已经过期等流量可以直接拦截。而对于有资格进入拆红包的请求量，也做流量控制。通过这些处理，最后可进入拆环节的流量大大减少，并且都是有效请求。
3) 拆时内存cache控制（？）
针对同一个红包并发拆的控制，上面的文章已介绍。
4、DB简化和拆分
DB的并发能力，有很多影响因素。红包系统结合红包使用情境，进行了一些优化。比较有借鉴意义的，主要有以下两点：
1) 订单表只存关键字段，其他字段只在cache中存储，可柔性。
红包详情的展示中，除了订单关键信息（用户、单号、金额、时间、状态）外，还有用户头像、昵称、祝福语等字段。这些字段对交易来说不是关键信息，却占据大量的存储空间。
将这些非关键信息拆出来，只存在cache，用户查询展示，而订单中不落地。这样可以维持订单的轻量高效，同时cache不命中时，又可从实时接口中查询补偿，达到优化订单DB容量的效果。
2) DB双重纬度分库表，冷热分离
四、红包算法（要细看）
首先，如果红包只有一个，本轮直接使用全部金额，确保红包发完。
然后，计算出本轮红包最少要领取多少，才能保证红包领完，即本轮下水位；轮最多领取多少，才能保证每个人都领到，即本轮上水位。主要方式如下：
计算本轮红包金额下水位：假设本轮领到最小值1分，那接下来每次都领到200元红包能领完，那下水位为1分；如果不能领完，那按接下来每次都领200元，剩下的本轮应全部领走，是本轮的下水位。
计算本轮红包上水位：假设本轮领200元，剩下的钱还足够接下来每轮领1分钱，那本轮上水位为200元；如果已经不够领，那按接下来每轮领1分，计算本轮的上水位。
为了使红包金额不要太悬殊，使用红包均值调整上水位。如果上水位金额大于两倍红包均值，那么使用两倍红包均值作为上水位。换句话说，每一轮抢到的红包金额，最高为两倍剩下红包的均值。
最后，获取随机数并用上水位取余，如果结果比下水位还小，则直接使用下水位，否则使用随机金额为本轮拆到金额。
五、柔性降级方案
系统到处存在发生异常的可能，需要对所有的环节做好应对的预案。下面列举微信红包对系统异常的主要降级考虑。
1、 下单cache故障降级DB
下单cache有两个作用，生成红包订单与订单缓存。缓存故障情况下，降级为直接落地DB，并使用id生成器独立生成订单号。
2、 抢时cache故障降级DB
抢红包时，查询cache，拦截红包已经抢完、用户已经抢过、红包已经过期等无效请求。当cache故障时，降级DB查询，同时打开DB限流保护开关，防止DB压力过大导致服务不可用。
另外，cache故障降级DB时，DB不存储用户头像、用户昵称等（上文提到的优化），此时一并降级为实时接口查询。查询失败，继续降级为展示默认头像与昵称。
3、 拆时资金入账多级柔性
拆红包时，DB记录拆红包单据，然后执行资金转账。单据需要实时落地，而资金转账，这里做了多个层级的柔性降级方案：
大额红包实时转账，小额红包入队列异步转账 所有红包进队列异步转账 实时流程不执行转账，事后凭单据批量入账。
总之，单据落地后，真实入账可实时、可异步，最终保证一致即可。
4、 用户列表降级
用户列表数据在微信红包系统中，属于非关键路径信息，属于可被降级部分。
首先，写入时通过MQ异步写，通过定时对账保证一致性。
其次，cache中只缓存两屏，用户查询超过两屏则查用户列表DB。在系统压力大的情况下，可以限制用户只查两屏。