第1章容错与降级概述

一、容错与降级概述

大家好，我是老张。在交易系统这个行当摸爬滚打了十几年，今天咱们聊聊容错与降级。这两个词，说白了就是系统出问题时，怎么让它还能继续干活，别直接躺平。

容错，字面意思就是「容忍错误」。系统里某个组件挂了，但整体功能不受影响，或者影响很小。我习惯把它理解成「系统自带的金钟罩」。

举个例子：你有个订单服务集群，三台机器同时运行。其中一台突然宕机了，另外两台还能继续处理订单。用户完全感知不到异常。这就是容错。

核心要点：容错不是避免错误，而是错误发生后系统依然可用。

我在项目中遇到过一种情况：数据库主库挂了，从库自动接管。但切换过程中有几百毫秒的延迟，部分请求超时了。嗯，这里要注意——容错不是万能的，它只能保证「最终可用」，不是「零中断」。

降级，说白了就是「丢车保帅」。系统压力太大，或者部分功能不可用时，主动放弃一些非核心功能，保证核心功能正常运行。

你想想看，双十一零点，订单量暴增。这时候如果还让用户查历史订单、看商品详情、做个性化推荐，系统肯定扛不住。怎么办？把非核心功能暂时关掉，只保留下单、支付这些核心链路。这就是降级。

个人经验：我曾经在某个大促项目中，把用户头像加载、评论展示、搜索推荐全部降级了。结果核心交易链路扛住了，系统稳稳的。事后复盘，大家一致认为降级策略救了我们一命。

交易系统有个特点：高可用、高并发、强一致性。这三个要求放在一起，本身就是个难题。

这三个目标互相打架。你追求高可用，就得容忍部分数据不一致；你追求强一致性，性能就会下降。容错和降级，就是在这三者之间找平衡。

我记得有一次，某大厂因为缓存集群故障，导致所有请求都打到数据库。数据库瞬间被打爆，整个交易系统瘫痪了整整20分钟。损失了多少？几千万。如果当时有合理的降级策略，把缓存降级为本地缓存，或者直接限流，结果会完全不同。

避坑指南：我曾经见过一个团队，把所有服务都做了容错，但没做降级。结果某个非核心服务挂了，触发熔断，熔断又导致连锁反应，最后核心链路也崩了。记住：容错和降级要一起用，缺一不可。

做容错降级设计，我总结了四个原则，都是血泪教训换来的：

原则	说明	我的经验
1. 隔离原则	不同服务、不同模块之间要隔离，一个挂了不影响其他	我曾经用线程池隔离，结果一个慢接口把线程池占满了，其他接口也进不来。后来改用信号量隔离，好多了
2. 快速失败原则	发现异常要尽快返回，别死等	超时设置一定要有。我见过一个接口默认超时30秒，结果用户等得直接关浏览器了
3. 有损服务原则	降级时允许部分功能不可用，但核心功能必须保住	说白了就是「砍掉锦上添花，保住雪中送炭」
4. 可回滚原则	降级策略要能快速恢复，不能降下去就起不来了	我习惯用配置中心控制降级开关，一键降级，一键恢复

这四个原则，我建议你记在心里。每次做设计时，拿这四个原则过一遍，能避免很多坑。

下面这张图，是我自己画的容错降级知识体系。你看一眼，心里就有数了：

这张图把容错降级分成了四个维度：容错、降级、设计原则、应用场景。后面几章，我们会逐个深入讲解。今天先把概念理清楚，后面就好办了。

一个小建议：刚开始接触容错降级时，别想着一步到位。先从最简单的「超时重试」做起，慢慢加上「熔断」「限流」「降级」。我当年就是这么一步步过来的。

公众号:蓝海资料掘金营，微信deep3321