分布式系统学习：15 弹力设计篇：熔断设计

关键词总结：熔断设计、熔断设计的重点

熔断设计

分布式系统设计中，重试时如果错误太多，或是在短时间内得不到修复，应该开启熔断操作，尤其是后端太忙的时候，使用熔断设计可以保护后端不会过载。

熔断器模式：1、可以防止应用程序不断地尝试执行可能会失败的操作，或者浪费 CPU 时间去等待长时间的超时产生。2、使应用程序能够诊断错误是否已经修正。如果已经修正，应用程序会再次尝试调用操作。

熔断器可以使用状态机来实现，内部模拟以下几种状态。

闭合（Closed）状态

失败的计数器 -> 调用失败，失败次数+1 -> 最近失败次数超过了允许失败的阈值 -> 切换到断开 (Open) 状态 -> 开启一个超时时钟 -> 时钟超过了该时间 -> 切换到半断开（Half-Open）状态。
超时时钟：给了系统一次机会来修正导致调用失败的错误
Closed 状态下：错误计数器（基于时间或者连续失败的次数） 在特定的时间间隔或者次数内会自动重置。防止由于某次的偶然错误导致熔断器进入断开状态

断开 (Open) 状态

在该状态下，立即对请求返回错误响应，而不调用后端的服务。有时也可以cache上次成功请求，直接返回缓存（不能影响业务）

半开（Half-Open）状态

允许应用程序一定数量的请求去调用服务。能够有效防止正在恢复中的服务被突然而来的大量请求再次拖垮。

如果请求成功，那么可以认为之前导致调用失败的错误已经修正，熔断器切换到闭合状态，同时将错误计数器重置。

如果这一定数量的请求有调用失败，认为导致之前调用失败的问题仍然存在，熔断器切回到断开状态，重置计时器来给系统一定的时间来修正错误。

熔断设计的重点

实现熔断器模式的时候，需要考虑这些因素

• 错误的类型
  根据错误类型，来估计被调用方大概需要花费的恢复时长，进而作出合理的决定，是进入重试环节，还是直接做熔断操作。
• 日志监控
  记录所有失败请求和一些可能成功的请求。使得管理员能够监控熔断器执行情况
• 测试服务是否可用
  在断开状态下，熔断器可以采用定期地 ping 一下远程服务的健康检查接口，来判断服务是否恢复，而不是使用计时器来自动切换到半开状态。并且在服务恢复的情况下，不需要真实的用户流量请求把状态从半开状态切回关闭状态。
• 手动重置
  提供可以手动将熔断器状态切换至闭合或断开的功能。
• 并发问题
  相同的熔断器有可能被大量并发请求同时访问。使用无锁或原子性的方式来实现熔断器，以确保其本身不会产生阻塞的问题。
• 资源分区
  熔断器只对有问题的分区进行断开操作，确保其他分区还是可用的。
• 记录重试错误的请求
  有时候，错误和请求的数据和参数有关系，所以，记录下出错的请求，这需要被调用端支持幂等调用。

参考资料：

左耳听风（极客时间）链接：
http://gk.link/a/10f5D

---

GitHub链接：
https://github.com/lichangke/LeetCode
CSDN首页：
https://me.csdn.net/leacock1991
欢迎大家来一起交流学习