在非阻塞应用程序上应用 Bulkhead 模式的目的是什么？
What's the purpose of applying the Bulkhead pattern on a non-blocking application?
我对 Bulkhead 模式的理解是，它是一种隔离线程池的方式。因此，与不同服务的交互使用不同的线程池：如果共享同一个线程池，一个服务不断超时可能会耗尽整个线程池，从而中断与其他（健康的）服务的通信。通过使用不同的，可以减少影响。
根据我的理解，我认为没有任何理由将此模式应用于非阻塞应用程序，因为线程不会被阻塞，因此，无论哪种方式，线程池都不会耗尽。
如果有人能澄清这一点，我将不胜感激，以防我遗漏了什么。
编辑（解释为什么它不是重复的）：
还有另一个（更通用的）问题询问 why using Circuit-Breaker and Bulkhead patterns with Reactor。以非常通用的方式回答了这个问题，解释了为什么在使用 Reactor 时所有 Resilience4J 装饰器都是相关的。
另一方面，我的问题是 Bulkhead 模式特有的，因为我不明白它在线程不被阻塞的情况下的好处。
Bulkhead 模式不仅仅是隔离线程池。
想想Little's law：L = λ * W
其中：
L – 队列系统中的平均并发任务数
λ – 每单位时间到达排队系统的平均任务数
W – 任务在排队系统中花费的平均服务时间
隔板模式更多的是控制L以防止资源耗尽。这可以通过使用来完成：
- 有界队列+线程池
- 信号量
即使是 non-blocking 应用程序也需要您可能希望限制的每个并发任务的资源。信号量可以帮助限制并发任务的数量。
RateLimiter 模式是关于控制 λ 而 TimeLimiter 是关于控制允许任务花费的最长时间。
自适应 Bulkhead 甚至可以取代 RateLimiters。看看这个精彩的演讲 "Stop Rate Limiting! Capacity Management Done Right" by Jon Moore"
我们目前正在 Resilience4j 中开发 AdaptiveBulkhead，它可以动态调整任务的并发限制。该实现可与 TCP 拥塞控制算法相媲美，TCP 拥塞控制算法使用附加 increase/multiplicative 减少 (AIMD) 方案来动态适应拥塞 window。
但是 AdaptiveBulkhead 当然是 protocol-agnostic.
我对 Bulkhead 模式的理解是，它是一种隔离线程池的方式。因此，与不同服务的交互使用不同的线程池：如果共享同一个线程池，一个服务不断超时可能会耗尽整个线程池，从而中断与其他（健康的）服务的通信。通过使用不同的，可以减少影响。
根据我的理解，我认为没有任何理由将此模式应用于非阻塞应用程序，因为线程不会被阻塞，因此，无论哪种方式，线程池都不会耗尽。
如果有人能澄清这一点，我将不胜感激，以防我遗漏了什么。
编辑（解释为什么它不是重复的）：
还有另一个（更通用的）问题询问 why using Circuit-Breaker and Bulkhead patterns with Reactor。以非常通用的方式回答了这个问题，解释了为什么在使用 Reactor 时所有 Resilience4J 装饰器都是相关的。
另一方面，我的问题是 Bulkhead 模式特有的，因为我不明白它在线程不被阻塞的情况下的好处。
Bulkhead 模式不仅仅是隔离线程池。
想想Little's law：L = λ * W
其中：
L – 队列系统中的平均并发任务数
λ – 每单位时间到达排队系统的平均任务数
W – 任务在排队系统中花费的平均服务时间
隔板模式更多的是控制L以防止资源耗尽。这可以通过使用来完成：
- 有界队列+线程池
- 信号量
即使是 non-blocking 应用程序也需要您可能希望限制的每个并发任务的资源。信号量可以帮助限制并发任务的数量。
RateLimiter 模式是关于控制 λ 而 TimeLimiter 是关于控制允许任务花费的最长时间。
自适应 Bulkhead 甚至可以取代 RateLimiters。看看这个精彩的演讲 "Stop Rate Limiting! Capacity Management Done Right" by Jon Moore"
我们目前正在 Resilience4j 中开发 AdaptiveBulkhead，它可以动态调整任务的并发限制。该实现可与 TCP 拥塞控制算法相媲美，TCP 拥塞控制算法使用附加 increase/multiplicative 减少 (AIMD) 方案来动态适应拥塞 window。 但是 AdaptiveBulkhead 当然是 protocol-agnostic.