柔性降级方案-深圳抢红包的服务器一些软件规则略谈
系统到处存在发生异常的可能，需要对所有的环节做好应对的预案。下面列举微信红包对系统异常的主要降级考虑。
1、 下单cache故障降级DB
下单cache有两个作用，生成红包订单与订单缓存。缓存故障情况下，降级为直接落地DB，并使用id生成器独立生成订单号。
2、 抢时cache故障降级DB
抢红包时，查询cache，拦截红包已经抢完、用户已经抢过、红包已经过期等无效请求。当cache故障时，降级DB查询，同时打开DB限流保护开关，防止DB压力过大导致服务不可用。
另外，cache故障降级DB时，DB不存储用户头像、用户昵称等（上文提到的优化），此时一并降级为实时接口查询。查询失败，继续降级为展示默认头像与昵称。
3、 拆时资金入账多级柔性
拆红包时，DB记录拆红包单据，然后执行资金转账。单据需要实时落地，而资金转账，这里做了多个层级的柔性降级方案：
大额红包实时转账，小额红包入队列异步转账 所有红包进队列异步转账 实时流程不执行转账，事后凭单据批量入账。
总之，单据落地后，真实入账可实时、可异步，最终保证一致即可。
4、 用户列表降级
用户列表数据在微信红包系统中，属于非关键路径信息，属于可被降级部分。
首先，写入时通过MQ异步写，通过定时对账保证一致性。
其次，cache中只缓存两屏，用户查询超过两屏则查用户列表DB。在系统压力大的情况下，可以限制用户只查两屏。
调整后的系统经过了16年春节的实践检验，平稳地度过了除夕业务高峰，保障了红包用户的体验。
