分布式系统降级策略（一）

在开发高并发系统时，有很多方法来保护系统，如：缓存、降级、限流等。下面将介绍一下降级的策略。当系统访问量增多，服务响应时间长或者非核心服务影响了核心服务的性能时。这是如果需要保证核心服务的可用性，就需要对非核心业务执行一些降级处理。系统可以根据关键数据进行自动降级，也可以配置开关进行人工降级。

降级策略分类

降级按照是否可以自动化分为：自动开关降级和人工开关降级。按照读写功能可以分为：读服务降级和写服务降级。当从用户访问的整条链路来看，将会有以下多级降级策略：

• 页面降级：当在大促时，某些页面占用了稀缺资源，可以对整个页面进行降级；当页面上会异步加载推荐信息等一些非核心的业务时，此时如果响应变慢，则可以进行降级处理。
• 服务读降级：一般情况下，分布式应用当中都会有缓存，查询频率比较高的数据，一般都会从缓存中获取。但是有一些数据，如果直接从缓存中获取的话，有可能造成客户的投诉。比如用户账户余额，这个一般只从DB里面获取，而且是主库里面去读取。当大促来临时，此时可以降级为从库里面或者缓存里面去获取余额信息。
• 服务写降级：在秒杀抢购业务中，由于并发的数量比较大。除了在各个层面上限流、使用队列等方式应对，还可以对写库进行降级，可以将库存扣减操作在内存中进行，当高峰过去之后，再异步的同步至DB中做扣减操作。
• 其他类型：如在系统繁忙时，可以将爬虫的流量直接丢弃。当高峰过后，再自动恢复。秒杀业务中，风控系统可以识别刷子/机器人，然后可以直接对这些用户执行拒绝服务。

自动开关降级

自动降级是根据系统负载、资源使用情况等指标进行降级操作。

超时降级

当访问的数据库/HTTP服务/远程调用响应慢，如果此服务不是核心服务的话，可以在超时后执行自动降级。如商品详情页中的评论信息，可以在查询超时后直接降级，然后前端可以再进行单独的评论信息的查询。

统计失败次数降级

当系统依赖外部的接口调用失败达到一定次数时，可以自动降级。然后开启一个异步的线程去探测是否恢复，恢复后执行自动取消降级（银行/第三方渠道系统出现故障）。

故障降级

这里面的故障大多是指内部系统的故障。当系统发生故障时，处理的方案可以有：默认值（库存默认有货）、兜底数据（广告系统挂了，可以直接返回之前准备好的静态页面）、缓存等。

限流降级

当系统负载过大时，可以使用排队页面、无货或者错误页等。这里面会用到降级的一些技术方案，可以参考笔者的《分布式系统降级策略》。

人工开关降级

在大促期间可以通过线上监控发现一些问题。如果此时系统不能自动降级，就需要人工介入了。例如有些后台的定时任务，会占用一部分的系统资源。此时如果系统处于高负载的运行，则可以手工停掉定时任务。待峰值过去之后再恢复启动。通常情况下开关的配置文件会放到配置中心，配置中心的实现方式可以通过ZooKeeper、Redis、Consul等。

另外，对于新系统在进行灰度测试时，可以通过开关来控制是否引流。当发现灰度环境有问题时，可以通过开关降级，切换到线上环境中去。

---

参考：《亿级流量网站架构核心技术》
链接：http://moguhu.com/article/detail?articleId=78