降级响应设计原则：可用性、一致性、最终一致性
这章咱们聊点实在的。降级响应，说白了就是在系统扛不住的时候，你得主动丢掉一些东西，保住更重要的东西。那丢掉什么、保住什么？这就引出了三个设计原则：可用性、一致性、最终一致性。
我个人习惯把这三者看作一把三角尺的三个角。你不可能同时把三个角都顶到极致——那成本谁也扛不住。你想想看，CAP 定理早就告诉我们了：一致性 (C)、可用性 (A)、分区容错性 (P)，最多同时满足两个。降级场景下，分区往往是必然的（网络抖动、节点故障），所以 P 基本是默认选项。剩下的就是在 C 和 A 之间做选择。
我做过一个实时交易系统。当时流量峰值一上来，数据库连接池瞬间就满了。如果坚持强一致性，所有请求都得排队等锁，用户页面直接转圈转到超时。那场事故我到现在还记得——老板在旁边盯着，线上用户骂声一片。后来我们果断做了降级：交易状态先写入本地缓存，异步再同步到数据库。也就是放弃了一致性，保住了可用性。
核心结论：降级时，可用性往往是保底选项，一致性可以被放松，但必须设计出最终一致性的补偿机制。
1. 可用性优先：先让用户用起来
可用性的核心目标就是：请求不能被丢掉。哪怕返回一个“稍后重试”或者一个旧数据，也比直接报 500 强。
常见的降级手段有：
- 限流 – 超过阈值的请求直接返回降级响应，不处理业务逻辑。
- 熔断 – 下游服务挂了，快速失败，避免线程堆积。
- 本地缓存 – 缓存最近成功的数据，即使在依赖失效时也能返回合理结果。
- 静态兜底 – 比如商品详情页，直接返回缓存的静态页面，不查库存。
我在一个电商秒杀项目中遇到过：用户点击“立即购买”，系统需要校验库存、风控、优惠券、地址等等。流量高峰时，这些依赖有三个超时了。按以前的设计，必须等所有依赖都返回才能下单，结果用户等了 10 秒然后报错。后来我改成：只要库存校验通过，立刻返回“已收到订单，稍后通知您结算”，剩下的风控和优惠券走异步核对。用户体验从“卡死”变成了“秒回”。
小技巧：可用性降级的核心是在关键路径上使用“快速通过 + 异步补偿”，而不是等所有事都做完。
2. 一致性：该严格时就严格
不是所有场景都能放松一致性。举个例子：转账扣款。A 账户扣了 100 元，B 账户必须增加 100 元。如果降级时只记了扣款没记入账，对账时就会出大问题。
一致性分为几个级别：
| 级别 | 含义 | 典型场景 |
|---|---|---|
| 强一致性 | 写入后立即被所有读看到 | 金融交易、余额查询 |
| 弱一致性 | 写入后可能有一段时间读不到 | 新闻推送、用户昵称修改 |
| 最终一致性 | 经过一段时间后，所有副本最终一致 | DNS、缓存、异步消息 |
降级响应中，如果业务要求强一致性，那就要保证要么不降级（直接报错让用户重试），要么引入分布式事务或锁机制。但分布式事务太慢，降级时一般扛不住。所以我建议：先识别出哪些操作必须强一致，哪些可以放宽。
避坑提醒：我曾经在一个金融项目中，错误地把支付确认接口降级为“只扣款不记账”，导致晚上对账差了 200 多笔。那一次让我学会了：涉及钱的场景，降级方案宁可拒绝，也不能让数据乱掉。
3. 最终一致性：降级后的主流选择
大部分降级场景最终都会走向最终一致性。什么意思？就是：我不保证你立刻看到最新数据，但我保证过一会儿你能看到。
最终一致性的实现套路很成熟：
- 异步消息队列 – 把写操作丢进 MQ，消费者慢慢处理。
- 补偿事务（Saga） – 每个操作都设计一个反向补偿。如果后续失败，可以回滚。
- 定时对账 – 定期扫描差异，自动修复不一致的数据。
- 本地事件表 – 在业务数据库里记录“待发送事件”，后台任务重试发送。
// 示例：本地事件表 + 定时任务实现最终一致性
public void createOrder(Order order) {
// 1. 写入订单表（主事务）
orderDao.insert(order);
// 2. 写入事件表（同一个本地事务）
eventDao.insert(new Event("order.created", order.getId()));
// 3. 事务提交后，定时任务扫描未发送的事件
// 逐个发送到下游系统（库存、积分等）
// 如果发送失败，重试或记录异常，人工介入
}
你看，这里的关键是“本地事务 + 异步发送”。保证了数据库的强一致，而消息的送达是最终一致的。如果消息丢了，还有对账补偿。
我记得在做一个 UGC 社区时，用户发帖需要同时更新“帖子表”和“用户动态时间线”。两个数据源跨库，不能强一致。我们用的就是最终一致性：帖子先落库，然后发一条 MQ 消息让动态服务异步更新。如果更新失败，每 5 分钟跑一次对账，把漏掉的补上。用户不会立刻看到新帖，但几分钟后就能看到。完全够用。
降级原则总结：
- 必须高可用的场景：优先保可用性，牺牲强一致性，使用最终一致性补偿。
- 必须强一致性的场景：宁可拒绝请求，也不返回错误数据；降级只发生在非核心路径。
- 最终一致性是常态：设计方案时，先对着业务流程问自己：“如果这里延迟 10 秒钟，业务会炸吗？” 不会炸，就可以用异步。
SVG 图把上面讲的三个原则、它们的权衡和典型场景串起来了。你看，降级不是一拍脑袋随便丢功能，而是根据业务特点，在可用性、一致性、最终一致性之间做出选择。很多同学刚接触降级设计时，总觉得最终一致性是个“偷懒”的方案。其实不然——这是在复杂分布式环境下最务实的做法。
好，这章的原则就这么多。你想想看，你现在的系统里，哪些操作是可以放宽一致性的？如果明天就遇到流量洪峰，你的降级方案会优先保什么？思考这些，比背概念有用得多。