常见容错机制：failover ，failsafe，failfast ，failback，forking。
- Failover 失败自动切换：当出现失败，重试其它服务器，通常用于读操作（推荐使用）。 重试会带来更长延迟。如Mysql的双Master模式，当正在使用的Master出现故障时，可以拿备Master做主使用
- Failfast 快速失败：只发起一次调用，失败立即报错,通常用于非幂等性的写操作。 如果有机器正在重启，可能会出现调用失败 。以JAVA集合（Collection）的快速失败为例，当多个线程对同一个集合的内容进行操作时，就可能会产生fail-fast事件。例如：当某一个线程A通过iterator去遍历某集合的过程中，若该集合的内容被其他线程所改变了；那么线程A访问集合时，就会抛出ConcurrentModificationException异常（发现错误执行设定好的错误的流程），产生fail-fast事件。
- Failsafe 失败安全：出现异常时，直接忽略，通常用于写入审计日志等操作。 调用信息丢失 可用于生产环境 Monitor。维基百科上一个形象的例子是红绿灯的“冲突监测模块”当监测到错误或者冲突的信号时会将十字路口的红绿灯变为闪烁错误模式，而不是全部显示为绿灯。
- Failback 失败自动恢复：后台记录失败请求，定时重发。通常用于消息通知操作 不可靠，重启丢失。 可用于生产环境 Registry。
- Forking 并行调用多个服务器：只要一个成功即返回，通常用于实时性要求较高的读操作。 需要浪费更多服务资源 。
- Broadcast：广播调用，所有提供逐个调用，任意一台报错则报错。通常用于更新提供方本地状态 速度慢，任意一台报错则报错 。
| 策略名称 | 优点 | 缺点 | 主要应用场景 |
|---|---|---|---|
| Failover | 对调用者屏蔽调用失败的信息 | 增加RT，额外资源开销，资源浪费 | 对调用rt不敏感的场景 |
| Failfast | 业务快速感知失败状态进行自主决策 | 产生较多报错的信息 | 需要快速感知失败的场景 |
| Failsafe | 即使失败了也不会影响核心流程 | 对于失败的信息不敏感，需要额外的监控 | 旁路系统，失败不影响核心流程正确性的场景 |
| Failback | 失败自动异步重试 | 重试任务可能堆积 | 对于实时性要求不高，且不需要返回值的一些异步操作 |
| Forking | 并行发起多个调用，降低失败概率 | 消耗额外的机器资源，需要确保操作幂等性 | 资源充足，且对于失败的容忍度较低，实时性要求高的场景 |
| Broadcast | 支持对所有的服务提供者进行操作 | 资源消耗很大 | 通知所有提供者更新缓存或日志等本地资源信息 |
