Dubbo 有哪些集群容错策略？

简化版

Dubbo 的集群容错策略决定「调用某个提供者失败时怎么办」，内置几种：① Failover（失败自动切换，默认）——失败后自动重试其他提供者，适合读操作（幂等），但重试有次数限制；② Failfast（快速失败）——失败立即报错、不重试，适合非幂等的写操作（如新增记录，重试会重复）；③ Failsafe（失败安全）——失败直接忽略、只记日志，适合可有可无的操作（如记录日志、监控埋点）；④ Failback（失败自动恢复）——失败后记录，定时重发，适合消息通知类；⑤ Forking（并行调用）——同时调多个，只要一个成功就返回，适合实时性要求高、不惜资源的读；⑥ Broadcast（广播）——逐个调用所有提供者，适合通知所有节点更新。

详细版

六种容错策略：

策略	行为	适用场景
Failover（默认）	失败重试其他节点（默认重试 2 次）	读操作、幂等调用
Failfast	失败立即报错，不重试	非幂等写操作（新增）
Failsafe	失败忽略，记日志	可失败的操作（日志、监控）
Failback	失败记录，定时重发	消息通知、最终一致
Forking	并行调多个，一个成功即返回	实时性高、成本不敏感的读
Broadcast	逐个调所有节点，任一失败则失败	通知所有提供者（如刷新缓存）

配置：

@DubboReference(cluster = "failfast", retries = 0)
private OrderService orderService;

关键：Failover 的重试次数用 retries 配置（默认 2，即总共调用 3 次）；写操作要用 Failfast 避免重试导致数据重复。

完整版教学

一、集群容错要解决什么

Consumer 调用某个 Provider 时，可能失败——网络抖动、Provider 宕机、超时、业务异常。集群容错策略决定的就是：当一次调用失败时，Dubbo 该怎么处理——是重试其他节点、还是立即报错、还是忽略。选对策略很重要，尤其要区分读操作（可重试）和写操作（重试可能重复）。Dubbo 在集群层（Cluster）封装了多种容错策略。

二、Failover：失败自动切换（默认）

Failover（失败自动切换） 是 Dubbo 的默认策略：调用一个 Provider 失败后，自动重试列表里的其他 Provider，直到成功或达到重试上限。

重试次数：用 retries 配置，默认 2——注意这是「重试次数」，加上第一次调用，总共最多调用 3 次（1 次原始 + 2 次重试）。
适用：读操作、幂等操作。因为读/幂等操作重试多次结果一样，重试能提高成功率、屏蔽个别节点故障。
不适用：非幂等的写操作！比如「新增订单」，如果第一次其实成功了但响应超时，Failover 重试会再新增一条，导致数据重复。所以写操作绝不能用默认的 Failover（要么用 Failfast，要么保证幂等）。

三、Failfast：快速失败

Failfast（快速失败）：调用失败后立即抛出异常、不重试。

适用：非幂等的写操作——新增记录、扣款等不能重复执行的操作。失败就失败，交给上层处理，绝不重试以免重复。
这是写操作的常用容错策略（配合 retries=0）。

四、Failsafe 与 Failback：容忍失败

Failsafe（失败安全）：调用失败后直接忽略，只记录日志，不抛异常、不影响主流程。

适用：可有可无、失败无所谓的操作——如记录审计日志、监控埋点。这些失败了不该影响核心业务，所以「安全地忽略」。

Failback（失败自动恢复）：调用失败后记录下来，后台定时重发。

适用：消息通知类、允许延迟的最终一致场景。失败不立即报错，而是稍后自动重试补偿。

五、Forking 与 Broadcast：并行与广播

Forking（并行调用）：同时调用多个 Provider，只要有一个成功就立即返回（其他的结果忽略）。

适用：实时性要求高、但不惜消耗资源的读操作。并行调多个，取最快返回的，降低延迟、提高成功率。代价是消耗更多资源（一次逻辑调用产生多次实际调用），可用 forks 参数控制并行数。

Broadcast（广播调用）：逐个调用所有 Provider，任意一个失败则整体失败。

适用：需要通知所有提供者执行某操作的场景——比如通知所有节点刷新本地缓存、更新配置。要求每个节点都执行到，所以逐个都调。

六、常见误区与追问

这道题面试时最容易丢分的地方，是把「Dubbo 集群容错」答成一段泛泛的组件介绍。更稳的答法是先给结论，再沿着远程调用链路拆清楚流程，最后补上异常场景、数字边界和选型取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心定义	Dubbo 集群容错定义一次调用失败后如何处理，常见有 Failover、Failfast、Failsafe、Failback、Forking、Broadcast	不要停在名词解释
流程机制	选中 Invoker 发起调用 -> 调用超时或异常 -> Cluster 策略判断处理方式 -> 重试其他节点或直接失败 -> 返回结果或降级	说明谁触发、谁存储、谁通知、谁兜底
工程取舍	查询接口可 Failover 重试 2 次，扣款或下单接口通常避免自动重试，防止重复写	RPC 让调用写法像本地方法，但失败语义、网络延迟和版本兼容必须按远程系统处理

Dubbo 集群容错 面试拆解：
1. 选中 Invoker 发起调用
2. 调用超时或异常
3. Cluster 策略判断处理方式
4. 重试其他节点或直接失败
5. 返回结果或降级

记忆钩子：先拆代理、序列化、传输、寻址、容错，再说明超时、重试、幂等这些工程边界；回答时一定要落到题目中的「Dubbo 集群容错」，不要把相邻中间件的能力混着讲。

误区：失败后重试总是最安全。 写操作重试可能造成重复下单、重复扣款，必须先保证幂等。
误区：Failfast 是不可靠。 Failfast 适合非幂等写操作，快速暴露错误比盲目重试更安全。
误区：Broadcast 适合普通查询。 Broadcast 会调用所有提供者，常用于通知或缓存刷新，不适合高频普通查询。
追问：Failover 适合什么场景？ 适合读操作或幂等操作，失败后切换其他实例重试。
追问：Failback 和 Failsafe 区别是什么？ Failback 后台记录失败并定时重试，Failsafe 直接忽略异常返回。
追问：容错策略和超时怎么配合？ 总耗时约等于单次超时乘以尝试次数，所以重试次数不能随意加。

七、加强记忆

Dubbo 集群容错决定「调用失败怎么办」：① Failover（默认）——重试其他节点（retries 默认 2，共 3 次），适合读/幂等，写操作禁用（重试会重复）；② Failfast——立即报错不重试，适合非幂等写（新增/扣款）；③ Failsafe——忽略失败记日志，适合日志/监控等可失败操作；④ Failback——失败记录、定时重发，适合消息通知/最终一致；⑤ Forking——并行调多个、一个成功即返回，适合实时性高不惜资源的读；⑥ Broadcast——逐个调所有节点，适合通知全部节点刷新缓存/配置。核心区分：读用 Failover（可重试）、写用 Failfast（防重复）；记忆口诀：Failover 重试、Failfast 快挂、Failsafe 忽略、Failback 补偿、Forking 并行取快、Broadcast 通知全部。

简化版

详细版