七种容错策略分为事后弥补与事前保险两大类

容错策略回答的是”故障发生后该怎么办”，五种以Fail开头的策略是事后弥补： 故障转移（切到其他副本重试，但要限重试次数——若下游调用耗时已接近上游 超时阈值，重试反而无意义）；快速失败（不重试、立即报错，用于非幂等场景， 如银行扣款接口网络异常时无法判断是否已扣款，重试可能导致重复扣款）； 安全失败（旁路逻辑失败时直接返回零值当作成功，只记日志，适合审计/日志 这类不影响主业务结果的调用）；沉默失败（判定服务一段时间内不可用、暂停 向它分配流量，避免请求堆积消耗全局资源）；故障恢复（失败信息存入消息 队列、后台异步重试，是快速失败+异步补偿的组合，适合非实时性要求的主路 逻辑或不需要返回值的旁路逻辑）。另外两种是调用前就多重下注的事前保险： 并行调用（同时向多个副本发起请求，任一成功即算成功，用更高执行成本换 成功率和响应时间）；广播调用（同时向多个副本发起请求，要求全部成功才 算成功，典型用于”刷新分布式缓存”这类需要多点同步生效的操作）。理解这 七种策略不是要死记名字，而是要判断具体场景落在哪个象限：服务是否幂等、 故障是主路还是旁路、是否追求”多重下注”而非”故障后补救”。

结构图：

flowchart TD
    A[容错策略] --> B[事后弥补: Fail系列]
    A --> C[事前保险: 调用前多重下注]
    B --> B1[故障转移 Failover: 切副本重试, 有次数限制]
    B --> B2[快速失败 Failfast: 非幂等场景不重试]
    B --> B3[安全失败 Failsafe: 旁路失败当成功]
    B --> B4[沉默失败 Failsilent: 暂停分配流量]
    B --> B5[故障恢复 Failback: 异步补偿重试]
    C --> C1[并行调用 Forking: 任一成功即成功]
    C --> C2[广播调用 Broadcast: 全部成功才成功]