高并发应对策略：缓存、限流、降级
- 缓存：缓解系统负载压力，提高系统响应速度。Java web应用性能分析之【高并发之缓存-多级缓存】-CSDN博客
- 限流：控制并发访问量，保护系统免受过载影响。Java web应用性能分析之【高并发之限流】-CSDN博客
- 降级：保证核心功能的稳定性，舍弃非关键业务或简化处理。Java web应用性能分析之【高并发之降级】-CSDN博客
在前面的文章中我们已经概叙了保护软件系统的“三高”特性：高可用，高性能，高并发；以及应对高并发的三大利器：缓存、限流、降级；在前文中详细描述了“多级缓存”，“多级限流”，现在我们聊聊“降级”。说到高并发下的降级，一般都是要提：限流、熔断、降级、预热、背压。
限流规定一个上限，流量超过系统承载能力时，会直接拒绝服务熔断不因底层旁路应用的故障，造成系统雪崩。避免出现欲练此功，必先自宫的情况。降级从请求入口，大范围的灭掉过载请求预热给系统一些启动预热时间，加载缓存，避免资源死锁背压被调用方反馈自己的能力给调用方。温柔的调用，需要坚实的沟通
简单来讲，只要流量不进系统，什么都好说，降级是最威猛最霸道的手段；一旦流量进入系统，就要接受系统内一系列规则的制约，其中限流是最直接的手段，将请求拦在外面。虽然用户的请求失败了，但我的系统还能活；没有熔断的系统就很凶残，很容易让三流功能影响主要功能，所以要在合适的时候打开它；至于预热，不过是在爱情火花前的一系列前戏，直到服务的巅峰状态；当然，相对于请求扔出去就不管的模式，如果被调用方能够反馈自己的状态，那么请求方就可以根据需要加大或者缩减马力，这就是背压的思想。
这些手段，都是在有限的资源下，有效的处理手段。但如果公司有钱，有弹性处理手段，这些都会变成辅助手段。毕竟，当所有的服务，能够将自己的状态，反馈到监控中心，监控中心能够实现弹性扩容。只要服务拆分的满足水平扩展，我们只需要增加实例就够了。
详细参考：高并发中的 限流、熔断、降级、预热、背压！-腾讯云开发者社区-腾讯云
参考：https://www.jianshu.com/p/40e1b0fba22c
说到降级，其实很多人都知道，当我们访问量剧增、服务出现问题就需要降级，保证核心服务或者服务基本可用。
降级的核心目的就是要保证服务基本可用的，一般我们可以通过配置中心配置或人工配置一些关键数据，去进行降级。也可以手动进行降级。同时，需要注意的是，降级也需要根据系统的吞吐量、响应时间、可用率等条件进行手工降级或自动降级。
大多数人都是知道什么是降级，但是具体的操作，相信大多数人还是不知道的，这篇文章就是主要介绍怎么样降级，如何优雅的进行降级。下面是这篇文章的一些内容:
1 降级预案
2 自动开关降级
3 人工开关降级
4 读服务降级
5 写服务降级
6 多级降级
7、具体实现
使用Hystrix实现降级
使用Hystrix实现熔断
8 其他（配置中心这种）
一、降级预案
一般在降级之前，我们需要进行一些预案，涉及到对哪些系统进行降级，如何降级，降级方案。。。。比如，可以参考日志级别设置预案。
下面是日志级别:
一般：比如，有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级。
• 警告：有些服务在一 段时间内成功率有波动 （如在95-100% 之间），可以自动降级或人工降级，并发送告警。
• 错误：比如，可用率低于90%, 或者数据库连接池用完了，或者访问量突然猛增到系统能承受的最大阙值，此时，可以根据情况自动降级或者人工降级。
• 严重错误：比如，因为特殊原因数据出现错误，此时，需要紧急人工降级。
降级按照是否自动化可分为：自动开关降级和人工开关降级。
降级按照功能可分为：读服务降级和写服务降级。
降级按照处于的系统层次可分为：多级降级。
我们在降级时，主要从服务器端链路去考虑，用户访问了哪些调用链路来梳理，哪里需要降级。
• 页面降级: 在秒杀或者大促销的时候，一些页面占据了一些稀缺的资源，紧急情况下可以对整个页面降级。
• 页面片段降级: 页面的某些不重要的数据错误，可以对其降级，不显示。
• 服务功能降级：比如，渲染商品详情页时，需要调用一 些不太重要的服务 （相关分类、热销榜等），而这些服务在异常情况下直接不获取，即降级即可。
• 读降级：比如，多级缓存模式，如果后端服务有问题，则可以降级为只读缓存，这种方式适用于对读一 致性要求不高的场景。
• 写降级：比如，秒杀抢购，我们可以只进行Cache的更新，然后异步扣减库存到DB , 保证最终一 致性即可，此时可以将DB降级为Cache。
• 风控降级：如抢购／秒杀等业务，完全可以识别机器人、用户画像或者根据用户风控级别进行降级处理，直接拒绝高风险用户。
二、自动开关降级
自动降级是根据系统负载、资源使用情况、SLA等指标进行降级。
我们可以根据以下一些指标和方式进行降级:
-
超时
当访问的数据库/HTTP服务／远程调用响应慢或者长时间响应慢，且该服务不是核心服务的话，可以在超时后自动降级。在实际场景中一 定要配置好超时时间和超时重试次数及机制 -
统计失败次数降级
调用外部服务，当失败调用次数达到一 定阙值自动降级（熔断器）。然后通过异步线程去探测服务是否恢复了，恢复则取消降级。 -
故障降级
要调用的远程服务挂掉了（网络故障、DNS故障、HTTP服务返回错误的状态码、RPC服务抛出异常），则可以直接降级。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一 些静态页面）、缓存（之前暂存的一 些缓存数据）。 -
限流降级
当我们去秒杀或者抢购一 些限购商品时，可能会因为访问量太大而导致系统崩溃，此时，开发者会使用限流来限制访问量，当达到限流阙值时，后续请求会被降级。降级后的处理方案可以是：排队页面（将用户导流到排队页面等一 会儿重试）、无货 （直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。
三、人工开关降级
在大促期间通过监控发现线上的一 些服务存在问题，这个时候需要暂时将这些服务摘掉。有时通过任务系统调用一 些服务，但是，服务依赖的数据库可能存在：网卡打满了、数据库挂掉了或者很多慢查询，此时，需要暂停任务系统让服务方进行处理。
还有发现突然调用量太大，可能需要改变处理方式（比如同步转换为异步）。此时可以使用开关来完成降级。开关可以存放到配置文件、数据库、Redis/ZooKeeper。如果不是存放在本地，则可以定期同步开关数据（比如1秒同步一 次）。然后，通过判断某个key的值来决定是否降级。
四、读服务降级
对于读服务降级一 般采用的策略有：暂时切换读（降级到读缓存、降级到走静态化）、暂时屏蔽读（屏蔽读入口、屏蔽某个读服务）
页面降级、页面片段降级、页面异步请求降级都是读服务降级，目的是丢卒保帅（比如，因为这些服务也要使用核心资源，或者占了带宽影响到核心服务）
还有一 种是页面静态化场景。
动态化降级为静态化：
比如，平时网站可以走动态化渲染商品详情页，但是，到了大促来临之际可以将其切换为静态化来减少对核心资源的占用，而且可以提升性能。其他还有如列表页、首页、频道页都可以这么处理。可以通过一 个程序定期推送静态页到缓存或者生成到磁盘，出问题时直接切过去。
静态化降级为动态化：比如，当使用静态化来实现商品详情页架构时，平时使用静态化来提供服务，但是，因为特殊原因静态化页面有问题了，需要暂时切换回动态化来保证服务正确性。
五、写服务降级
写服务在大多数场景下是不可降级的，不过，可以通过一 些迂回战术来解决问题。比如，将同步操作转换为异步操作，或者限制写的量／比例。
比如扣减库存时的操作，我们都是先扣减缓存中的库存数据，再去扣减数据库的，但是如果是同步的扣减数据库，可能性能会扛不住，因为写入量比较大，此时可以这样降级:
正常情况下可以同步扣减库存，在性能扛不住时，降级为异步。另外，如果是秒杀场景可以直接降级为异步，从而保护系统。还有，如下单操作可以在大促时暂时降级，将下单数据写入Redis, 然后等峰值过去了再同步回DB.
适用的情况还有一种，比如一些不是很重要的实时数据，写入量很大时，可以直接降级为异步写入。
六、多级降级
降级是离用户越近越对系统保护得好。因为业务的复杂性导致越到后端QPS/TPS越低。什么意思呢？对于用户到服务端到数据持久层来说，浏览器离用户是最近的，离用户越近的时候降级越好。
可以参考下以下方式:
• 页面JS降级开关：主要控制页面功能的降级，在页面中，通过JS脚本部署功能降级开关，在适当时机开启／关闭开关。
• 接入层降级开关：主要控制请求入口的降级，请求进入后，会首先进入接入层，在接入层可以配置功能降级开关，可以根据实际情况进行自动／人工降级。尤其在后端应用服务出问题时，通过接入层降级从而给应用服务有足够的时间恢复服务。
• 应用层降级开关：主要控制业务的降级，在应用中配置相应的功能开关，根据实际业务情况进行自动／人工降级。
还有一种层次是在工作流程的每一个流程去控制进行响应的降级:
优先处理高优先级的数据、只处理某些特征数据、合理分配流量到最需要的场合。
七、实现--使用Hystrix实现熔断降级
参考：https://www.jianshu.com/p/40e1b0fba22c
八、实现--使用sentinel实现熔断降级
参考
扫一扫
868
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
