Hystrix使用的隔板图案是什么？ [英] What is Bulkhead Pattern used by Hystrix?

问题描述

Hystrix，用于复杂分布式系统中的延迟和容错的Netflix API，使用 Bulkhead 用于线程隔离的模式技术。有人可以详细说明一下。

Hystrix, a Netflix API for latency and fault tolerance in complex distributed systems uses Bulkhead Pattern technique for thread isolation. Can someone please elaborate on it.

推荐答案

常规

常规，隔板模式的目标是避免系统某一部分发生故障，从而使整个系统瘫痪。该术语来自将船舶划分为单独的水密舱室以避免将单个船体破损淹没整艘船舶的船舶；

General

In general, the goal of the bulkhead pattern is to avoid faults in one part of a system to take the entire system down. The term comes from ships where a ship is divided in separate watertight compartments to avoid a single hull breach to flood the entire ship; it will only flood one bulkhead.

根据需要保护系统的故障类型，实施隔板模式可以采用多种形式。我只会在此答案中讨论Hystrix处理的错误类型。

Implementations of the bulkhead pattern can take many forms depending on what kind of faults you want to protect the system from. I will only discuss the type of faults Hystrix handles in this answer.

我认为隔板模式已由 Release It！一书普及Michael T. Nygard。

I think the bulkhead pattern was popularized by the book Release It! by Michael T. Nygard.

Hystrix中的隔板实现限制了并发调用组件。这样，等待组件响应的资源（通常是线程）的数量就受到限制。

The bulkhead implementation in Hystrix limits the number of concurrent calls to a component. This way, the number of resources (typically threads) that is waiting for a reply from the component is limited.

假定您有一个基于请求的多线程应用程序（对于例如使用三个不同组件 A ， B 和 C 的典型Web应用程序）。如果对组件 C 的请求开始挂起，则最终所有请求处理线程将挂起，等待来自 C 的答复。这将使应用程序完全无响应。如果对 C 的请求处理缓慢，并且如果负载足够高，我们也会遇到类似的问题。

Assume you have a request based, multi threaded application (for example a typical web application) that uses three different components, A, B, and C. If requests to component C starts to hang, eventually all request handling threads will hang on waiting for an answer from C. This would make the application entirely non-responsive. If requests to C is handled slowly we have a similar problem if the load is high enough.

Hystrix对隔板模式的实现限制了组件的并发调用数，在这种情况下可以保存应用程序。假设我们有30个请求处理线程，并且最多只能有10个并发调用 C 。然后，调用 C 时最多可以挂起10个请求处理线程，而其他20个线程仍可以处理请求并使用组件 A 和 B 。

Hystrix' implementation of the bulkhead pattern limits the number of concurrent calls to a component and would have saved the application in this case. Assume we have 30 request handling threads and there is a limit of 10 concurrent calls to C. Then at most 10 request handling threads can hang when calling C, the other 20 threads can still handle requests and use components A and B.

Hystrix'具有两种不同的隔离方法，即线程隔离和信号量隔离。

Hystrix' has two different approaches to the bulkhead, thread isolation and semaphore isolation.

标准方法是将所有请求传递给组件 C

The standard approach is to hand over all requests to component C to a separate thread pool with a fixed number of threads and no (or a small) request queue.

另一种方法是让所有呼叫者在请求 C 之前获得许可（超时为0）。如果无法从信号量中获取许可，则不会传递对 C 的调用。

The other approach is to have all callers acquire a permit (with 0 timeout) before requests to C. If a permit can't be acquired from the semaphore, calls to C are not passed through.

线程池方法的优点是传递给 C 的请求可以超时，这在使用信号量时是不可能的。

The advantage of the thread pool approach is that requests that are passed to C can be timed out, something that is not possible when using semaphores.

这篇关于Hystrix使用的隔板图案是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！