共计 1063 个字符，预计需要花费 3 分钟才能阅读完成。
在上一节中，我们讨论了背压机制如何为系统划定稳定性边界。本篇将继续沿着“稳定性工程”的主线，系统讲解异步系统中三项必须成体系设计的能力：超时、重试与熔断 。它们共同面对一个现实前提： 失败不是异常，而是常态。
一、为什么必须显式设计失败路径
在真实环境中，任何依赖外部资源的操作都存在失败可能：
- 网络抖动
- 下游服务过载
- 数据源不稳定
- 临时不可达
如果系统的默认假设是“请求会成功”，那么在并发场景下，失败会以最糟糕的方式集中爆发。
工程化系统必须做到：
成功路径清晰，失败路径同样清晰。
二、超时：系统自我保护的第一道防线
超时的本质，是为一次操作设定“最大等待成本”。
在异步系统中，任何 IO 操作都必须有明确超时，否则就等同于：
- 任务永久占用资源
- Worker 被悄然耗尽
- 系统吞吐逐步下降
典型做法是使用统一的超时控制：
async def safe_call(coro, timeout=5):
return await asyncio.wait_for(coro, timeout)
需要强调的是：
超时不是异常情况，而是正常控制逻辑的一部分。
三、重试机制的设计边界
重试是把“双刃剑”：
- 合理的重试可以掩盖短暂波动
- 失控的重试会放大系统雪崩
工程上必须明确三点：
- 是否可重试（幂等性）
- 最大重试次数
- 重试间隔策略
一个基本原则是：
永远不要立即、无限、同步重试。
推荐采用：
- 有上限的重试次数
- 指数退避或随机延迟
- 与背压、并发控制联动
四、为什么需要熔断机制
当失败不再是“偶发”，而是“持续发生”时，重试本身就变成了系统负担。
熔断机制解决的是这个问题：
当下游明显不可用时，系统应当主动停止尝试。
熔断的核心状态通常包括：
- 关闭（正常）
- 打开（拒绝请求）
- 半开（试探恢复）
这使系统避免在“必然失败”的路径上继续消耗资源。
五、异步系统中的轻量级熔断思路
在 Python 异步系统中，熔断并不一定需要复杂框架。
一个简单可行的思路是：
- 统计连续失败次数
- 超过阈值后短时间内直接失败
- 定期允许少量请求探测恢复情况
这种设计成本极低，但稳定性收益极高。
六、三者之间的协同关系
超时、重试、熔断不是独立存在的，而是一个完整体系：
- 超时：防止单次请求失控
- 重试：应对短暂异常
- 熔断：应对系统性失败
缺失任何一个，系统都会在压力下暴露结构性缺陷。
七、从“异常处理”到“失败设计”的思维转变
至此，你需要完成一个重要认知升级：
- 不再把失败当作“意外情况”
- 而是当作“系统输入的一部分”
能够主动设计失败路径的工程师，
才真正具备构建高并发、高可用系统的能力。
下一篇，我们将继续完善异步系统的稳定性拼图：
异步系统中的状态管理与一致性——在并发环境下保持系统可信度。
