数据库降级_「聊聊高并发 三」降级篇

「聊聊高并发 三」降级篇

高并发系统保护的三把利器 : 缓存、降级和限流。

今天主要来聊聊降级

当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时，仍然需要保证核心服务还是可用的，即使是有损其他服务，系统可以根据一些关键数据进行自动降级或者配置开关实现人工降级

降级的最终目的是保证核心服务可用，通过在服务压力剧增的时候根据当前的业务情况及流量对一些服务和页面有策略的降级，以此环节服务器的压力，以保证核心任务的进行，同时保证部分甚至大部分任务客户能得到正确的相应。也就是当前的请求处理不了了或者出错了，给一个默认的响应。

一、降级预案

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

• 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
• 警告：有些服务在一段时间内成功率有波动(如在95~100%之间)，可以自动降级或人工降级，并发送告警；
• 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
• 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级

二、降级分类

降级按照是否自动化可分为：自动开关降级和人工开关降级

自动降级方式

• 超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况
• 失败次数降级：主要是一些不稳定的API，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况
• 故障降级：比如要调用的远程服务挂掉了(网络故障、DNS故障、HTTP服务返回异常状态码、RPC服务抛出异常)，则可以直接降级。降级后的处理方案有：默认值(比如库存服务挂了，返回默认现货)、兜底数据(比如广告挂了，返回提前准备好的一些静态页面)、缓存(之前暂存的一些缓存数据)
• 限流降级：当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面(将用户导流到排队页面等一会重试)、无货(直接告知用户没货了)、错误页(如活动太火爆了，稍后重试)

降级按照功能可分为：读服务降级、写服务降级

读服务降级

• 暂时切换读(降级到读缓存、降级到走静态化)
• 暂时屏蔽读(屏蔽读入口、屏蔽某个读服务)

写服务降级

• 同步操作转换为异步操作
• 限制写的量/比例
• 写数据库转为先写缓存

降级按照处于的系统层次可分为：多级降级

缓存是离用户最近越高效；而降级是离用户越近越能对系统保护的好。因为业务的复杂性导致越到后端QPS/TPS越低。

页面JS降级开关：主要控制页面功能的降级，在页面中通过JS脚本部署功能降级开关，在适当时机开启/关闭开关；

接入层降级开关：主要控制请求入口的降级，请求进入后会首先进入接入层，在接入层可以配置功能降级开关，可以根据实际情况进行自动/人工降级；

应用层降级开关：主要控制业务的降级，在应用中配置相应的功能开关，根据实际业务情况进行自动/人工降级。

三、降级实现

Hystrix是什么

在分布式环境中，许多服务依赖项中的一些必然会失败。Hystrix是一个库，通过添加延迟容忍和容错逻辑，帮助你控制这些分布式服务之间的交互。Hystrix通过隔离服务之间的访问点、停止级联失败和提供回退选项来实现这一点，所有这些都可以提高系统的整体弹性。

Hystrix的Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.告知后面的请求服务不可用了，不要再来了。