Hystrix是Netflix API，用于复杂分布式系统中的延迟和容错，它使用隔板模式技术进行线程隔离。有人可以详细说明。
答案 0 :(得分：151)
通常，隔板模式的目标是避免系统某个部分出现故障以使整个系统停机。该术语来自船舶，船舶在不同的水密舱室中分开，以避免单一的船体破坏使整艘船舶泛滥;它只会淹没一个舱壁。
隔板模式的实现可以采用多种形式，具体取决于您希望保护系统的故障类型。我将只讨论Hystrix在这个答案中处理的故障类型。
我认为舱壁模式是由Michael T. Nygard出版的 Release It！一书推广的。
Hystrix 中的隔板实现限制了对组件的并发调用数。这样，等待组件回复的资源（通常是线程）数量是有限的。
假设您有一个基于请求的多线程应用程序（例如典型的Web应用程序），它使用三个不同的组件， A ， B 和 C 即可。如果对组件 C 的请求开始挂起，则最终所有请求处理线程将在等待来自 C 的答案时挂起。这将使应用程序完全无响应。如果对 C 的请求处理缓慢，如果负载足够高，我们会遇到类似的问题。
Hystrix对隔板模式的实现限制了对组件的并发调用次数，并且在这种情况下会保存应用程序。假设我们有30个请求处理线程，并且有10个并发调用 C 的限制。然后，在调用 C 时，最多可以挂起10个请求处理线程，其他20个线程仍然可以处理请求并使用 A 和 B 组件。< / p>
Hystrix'有两种不同的隔板，线程隔离和信号量隔离方法。
标准方法是将对组件 C 的所有请求移交给具有固定数量的线程且没有（或小）请求队列的单独线程池。
另一种方法是让所有呼叫者在对 C 的请求之前获得许可（0超时）。如果无法从信号量获取许可，则不会传递对 C 的呼叫。
线程池方法的优点是传递给 C 的请求可以超时，这在使用信号量时是不可能的。
答案 1 :(得分：0)
以下是受Netflix Hystrix启发的Resilience4j中的good example with runtime explanation舱壁。
下面的示例配置可能使用法更加清晰。
示例配置：在任何给定时间最多允许5个并发呼叫。让其他呼叫一直等待，直到正在进行的5个并发之一完成或最多2秒为止。
想法不应使任何系统负担的负载超出其负担。如果传入的负载大于消耗的负载，则请等待一段合理的时间，或者等待超时并选择备用路径。
答案 2 :(得分：0)
Bulkhead 模式是一种用于隔离和容错的设计模式。
在微服务中，一个服务可能依赖于许多其他服务，如果其中一个依赖服务宕机或访问超时，调用者可能会耗尽资源，其他正常服务将无法调用强>;如果我们使用bulkhead模式通过不同的线程池对服务进行分组和隔离，那么当一个线程池耗尽时，其他线程组的资源不会受到影响，其他服务的正常调用也不会受到影响。
你可以参考这个：Bulkhead pattern