文章目录先说结论Failover换家店试试Failfast不行就算了Failsafe忘了这事Failback回头再说Forking同时点几家Broadcast通知所有人怎么选择回答技巧与点评加分回答面试官点评个人网站分布式系统中服务调用失败是家常便饭——网络抖动、服务重启、机房故障……问题不是会不会失败而是失败了怎么办。Dubbo 提供了多种集群容错策略面试官问这题他想听的是每种策略的原理是什么适用什么场景你项目里用的哪种先说结论策略行为适用场景Failover失败自动切换其他提供者重试读操作默认Failfast失败立即报错非幂等写操作Failsafe失败忽略返回空结果日志等非关键操作Failback失败自动记录定时重发消息通知等最终一致场景Forking并行调用多个取最快返回实时性要求高的读操作Broadcast逐个调用所有提供者通知所有节点更新缓存一句话记住Failover 是换家店试试Failfast 是不行就算了Failsafe 是忘了这事Failback 是回头再说Failover换家店试试默认策略。调用失败后自动切换到其他提供者重试。默认重试 2 次共调用 3 次。DubboReference(retries2)// 失败重试 2 次总共调用 3 次privateUserServiceuserService;dubbo:consumer:retries:2# 全局默认重试次数就像你去餐厅点菜第一家说售完了你自动换第二家点——总有一家能做。注意重试会带来延迟每次超时等一段时间也可能导致重复写入如果是写操作。所以 Failover只适合读操作写操作必须用 Failfast。Failfast不行就算了只调用一次失败立即报错不重试。DubboReference(clusterfailfast)// 失败直接抛异常privateOrderServiceorderService;适合非幂等写操作——创建订单、扣款等。重试可能导致重复下单比失败更可怕。就像医院挂号——挂不上就挂不上你不能自动换家医院挂号因为可能挂重了。Failsafe忘了这事调用失败时忽略异常返回空结果。DubboReference(clusterfailsafe)privateLogServicelogService;适合非关键操作——写日志、发通知、更新缓存等。失败了不影响主流程。就像你在饭馆吃饭服务员忘了送小菜——无所谓不影响吃主菜。Failback回头再说调用失败时记录请求到失败队列定时重发。DubboReference(clusterfailback)privateNotificationServicenotificationService;适合最终一致性场景——消息通知、数据同步等。失败了不急着重试后台慢慢补。就像快递送不到——先放快递柜回头再来取。Dubbo 默认每 5 秒重试一次失败记录。注意如果失败请求堆积太多可能导致内存溢出。生产环境需监控失败队列长度。Forking同时点几家同时调用多个提供者取最快返回的那个。DubboReference(clusterforking,forks3)// 并行调用 3 个privateSearchServicesearchService;适合实时性要求高的读操作——搜索引擎、推荐系统等。不追求所有结果谁最快用谁。就像你同时叫了 3 辆出租车谁先到坐谁——快就是正义。注意并行调用会浪费服务器资源3 次调用只有 1 次有效forks 数量不宜过大。Broadcast通知所有人逐个调用所有提供者任意一个报错则报错。DubboReference(clusterbroadcast)privateCacheServicecacheService;适合通知所有节点的场景——更新缓存、刷新配置等。每个节点都得通知到。就像公司广播——通知所有部门开会不能漏掉任何一个。怎么选择操作类型推荐策略原因读操作Failover天然幂等重试安全写操作非幂等Failfast避免重复写入非关键操作Failsafe失败不影响主流程消息通知Failback最终一致即可实时性要求高Forking并行取最快全节点通知Broadcast每个都得通知Dubbo 集群容错全景 六种策略 ├── Failover —— 失败重试默认适合读 ├── Failfast —— 快速失败适合非幂等写 ├── Failsafe —— 安全失败适合非关键操作 ├── Failback —— 失败重发适合最终一致 ├── Forking —— 并行调用适合实时读 └── Broadcast —— 广播调用适合全节点通知 选择原则 ├── 读操作 → Failover ├── 写操作 → Failfast ├── 非关键 → Failsafe ├── 通知类 → Failback / Broadcast └── 实时性 → Forking 核心风险 ├── Failover 重试导致写重复 ├── Failback 失败队列堆积 └── Forking 并行浪费资源 口诀Failover换家试Failfast直接报 Failsafe无所谓Failback回头搞 Forking并行跑Broadcast全员到 读写区分最关键幂等重试才安全回答技巧与点评标准回答Dubbo 提供 6 种集群容错策略Failover失败自动重试默认适合读操作、Failfast快速失败适合非幂等写操作、Failsafe忽略异常适合非关键操作、Failback失败定时重发适合最终一致场景、Forking并行调用取最快适合实时读、Broadcast广播调用所有节点适合通知类操作。选择的关键在于区分读写操作和幂等性。加分回答幂等性是重试的前提Failover 重试意味着同一请求可能被多次执行只有读操作和幂等写操作才能安全重试。非幂等写操作如下单、扣款必须用 Failfastretries 的计算retries2 表示失败后重试 2 次总共调用 3 次1 次正常 2 次重试。超时时间要合理设置避免重试导致响应时间成倍增加自定义容错策略Dubbo 通过 SPI 机制支持自定义 Cluster 实现你可以根据业务需求实现自己的容错逻辑比如失败后降级到缓存的混合策略面试官点评这道题考的是你对分布式容错设计的理解。能说出 3-4 种策略算及格高分的关键在于讲清楚每种策略的适用场景和风险特别是 Failover 重试可能导致写重复的问题。如果你能提到幂等性是重试的前提说明你有实战经验。原文阅读内容有帮助点赞、收藏、关注三连评论区等你
孤舟笔记 互联网常用框架篇二 Dubbo服务请求失败怎么处理？集群容错策略你用过几种
文章目录先说结论Failover换家店试试Failfast不行就算了Failsafe忘了这事Failback回头再说Forking同时点几家Broadcast通知所有人怎么选择回答技巧与点评加分回答面试官点评个人网站分布式系统中服务调用失败是家常便饭——网络抖动、服务重启、机房故障……问题不是会不会失败而是失败了怎么办。Dubbo 提供了多种集群容错策略面试官问这题他想听的是每种策略的原理是什么适用什么场景你项目里用的哪种先说结论策略行为适用场景Failover失败自动切换其他提供者重试读操作默认Failfast失败立即报错非幂等写操作Failsafe失败忽略返回空结果日志等非关键操作Failback失败自动记录定时重发消息通知等最终一致场景Forking并行调用多个取最快返回实时性要求高的读操作Broadcast逐个调用所有提供者通知所有节点更新缓存一句话记住Failover 是换家店试试Failfast 是不行就算了Failsafe 是忘了这事Failback 是回头再说Failover换家店试试默认策略。调用失败后自动切换到其他提供者重试。默认重试 2 次共调用 3 次。DubboReference(retries2)// 失败重试 2 次总共调用 3 次privateUserServiceuserService;dubbo:consumer:retries:2# 全局默认重试次数就像你去餐厅点菜第一家说售完了你自动换第二家点——总有一家能做。注意重试会带来延迟每次超时等一段时间也可能导致重复写入如果是写操作。所以 Failover只适合读操作写操作必须用 Failfast。Failfast不行就算了只调用一次失败立即报错不重试。DubboReference(clusterfailfast)// 失败直接抛异常privateOrderServiceorderService;适合非幂等写操作——创建订单、扣款等。重试可能导致重复下单比失败更可怕。就像医院挂号——挂不上就挂不上你不能自动换家医院挂号因为可能挂重了。Failsafe忘了这事调用失败时忽略异常返回空结果。DubboReference(clusterfailsafe)privateLogServicelogService;适合非关键操作——写日志、发通知、更新缓存等。失败了不影响主流程。就像你在饭馆吃饭服务员忘了送小菜——无所谓不影响吃主菜。Failback回头再说调用失败时记录请求到失败队列定时重发。DubboReference(clusterfailback)privateNotificationServicenotificationService;适合最终一致性场景——消息通知、数据同步等。失败了不急着重试后台慢慢补。就像快递送不到——先放快递柜回头再来取。Dubbo 默认每 5 秒重试一次失败记录。注意如果失败请求堆积太多可能导致内存溢出。生产环境需监控失败队列长度。Forking同时点几家同时调用多个提供者取最快返回的那个。DubboReference(clusterforking,forks3)// 并行调用 3 个privateSearchServicesearchService;适合实时性要求高的读操作——搜索引擎、推荐系统等。不追求所有结果谁最快用谁。就像你同时叫了 3 辆出租车谁先到坐谁——快就是正义。注意并行调用会浪费服务器资源3 次调用只有 1 次有效forks 数量不宜过大。Broadcast通知所有人逐个调用所有提供者任意一个报错则报错。DubboReference(clusterbroadcast)privateCacheServicecacheService;适合通知所有节点的场景——更新缓存、刷新配置等。每个节点都得通知到。就像公司广播——通知所有部门开会不能漏掉任何一个。怎么选择操作类型推荐策略原因读操作Failover天然幂等重试安全写操作非幂等Failfast避免重复写入非关键操作Failsafe失败不影响主流程消息通知Failback最终一致即可实时性要求高Forking并行取最快全节点通知Broadcast每个都得通知Dubbo 集群容错全景 六种策略 ├── Failover —— 失败重试默认适合读 ├── Failfast —— 快速失败适合非幂等写 ├── Failsafe —— 安全失败适合非关键操作 ├── Failback —— 失败重发适合最终一致 ├── Forking —— 并行调用适合实时读 └── Broadcast —— 广播调用适合全节点通知 选择原则 ├── 读操作 → Failover ├── 写操作 → Failfast ├── 非关键 → Failsafe ├── 通知类 → Failback / Broadcast └── 实时性 → Forking 核心风险 ├── Failover 重试导致写重复 ├── Failback 失败队列堆积 └── Forking 并行浪费资源 口诀Failover换家试Failfast直接报 Failsafe无所谓Failback回头搞 Forking并行跑Broadcast全员到 读写区分最关键幂等重试才安全回答技巧与点评标准回答Dubbo 提供 6 种集群容错策略Failover失败自动重试默认适合读操作、Failfast快速失败适合非幂等写操作、Failsafe忽略异常适合非关键操作、Failback失败定时重发适合最终一致场景、Forking并行调用取最快适合实时读、Broadcast广播调用所有节点适合通知类操作。选择的关键在于区分读写操作和幂等性。加分回答幂等性是重试的前提Failover 重试意味着同一请求可能被多次执行只有读操作和幂等写操作才能安全重试。非幂等写操作如下单、扣款必须用 Failfastretries 的计算retries2 表示失败后重试 2 次总共调用 3 次1 次正常 2 次重试。超时时间要合理设置避免重试导致响应时间成倍增加自定义容错策略Dubbo 通过 SPI 机制支持自定义 Cluster 实现你可以根据业务需求实现自己的容错逻辑比如失败后降级到缓存的混合策略面试官点评这道题考的是你对分布式容错设计的理解。能说出 3-4 种策略算及格高分的关键在于讲清楚每种策略的适用场景和风险特别是 Failover 重试可能导致写重复的问题。如果你能提到幂等性是重试的前提说明你有实战经验。原文阅读内容有帮助点赞、收藏、关注三连评论区等你
