四．服务降级方案

我们对摇一摇/朋友圈红包照片在2016.1.26的预热活动和2016.2.7的正式活动都做了详细的复盘。包括活动过程中各项业务数据是否符合预期，各个模块的表现是否符合预期等，并分析各种不符合预期表现的成因和解决措施。

在红包系统的信息流、业务流和资金流都有很多保障用户核心体验的降级方案。举几个信息流的降级方案的例子。

a）如果某一个数据园区出现网络分裂等故障，完全不可用了，部署在那里的红包怎么发下去？

红包文件虽然在园区间有冗余存储，但基于性能和可用性考虑，我们并不打算在各园区间维护强一致的红包发放记录，做到记录级的“断点续发”，而是将红包文件按时段进行切分，降级为只做文件级的“断点续发”。在某个园区不可用时，使用降级方案后，故障园区当前发放时段的红包文件不会接着发放，仅保证下一时段的红包能通过其他园区正常发出去。

b）活动过程中，如果用户的交互量超过服务的处理能力了怎么办？

正如前面所述，我们很难准确估计参与用户量及互动次数。就本次活动而言，在系统设计之初，我们评估有2000万次/秒的峰值请求，并在系统最终实现和部署时预留了一定的余量，提供了评估值2.5倍（也就是5000万次/秒峰值请求）的系统处理能力，除夕当晚服务器处理请求峰值达到2500万次/秒，服务实际负载低于50%。但如果当时用户过多，互动过于火爆，到达后台的请求超过5000万次/秒，系统就会进入降级模式，客户端可以在服务器的控制下，减少请求，防止服务器过载。

c）红包发放速度过快，后端处理不过来怎么办？

正如前面所述，用户抢红包是在信息流完成的，完成后请求放到红包异步队列再转到业务流。如果领取红包请求量过大，队列会出现积压，红包的入账会出现延时，但不会导致用户请求失败。

类似的降级方案还有很多，每个环节都有若干个不同的降级方案，有些是针对业务专门设计的（如a和b），还有些是使用基础组件/服务/方案本身就具备的降级能力（如c）。这些方案都遵循着一个原则：降级时，尽可能保证用户的核心体验。