spring-webflux - 在非阻塞应用程序上应用 Bulkhead 模式的目的是什么？

Question

我对 Bulkhead 模式的理解是，它是一种隔离线程池的方式。因此，与不同服务的交互使用不同的线程池：如果共享同一个线程池，一个服务不断超时可能会耗尽整个线程池，从而中断与其他（健康）服务的通信。通过使用不同的，可以减少影响。

根据我的理解，我认为没有任何理由将此模式应用于非阻塞应用程序，因为线程不会被阻塞，因此线程池不会以任何方式耗尽。

如果有人能澄清这一点，以防我遗漏了什么，我将不胜感激。

编辑（解释为什么它不是重复的）：

还有另一个（更通用的）问题询问为什么将 Circuit-Breaker 和 Bulkhead 模式与 Reactor 一起使用。这个问题以非常通用的方式回答，解释了为什么所有 Resilience4J 装饰器在使用 Reactor 时都是相关的。

另一方面，我的问题是 Bulkhead 模式特有的，因为我不明白它在线程不被阻塞的情况下的好处。

标签： spring-webfluxproject-reactorresilience4j

Answer 1

Bulkhead 模式不仅仅是关于隔离线程池。

想想利特尔定律：L = λ * W

在哪里：

L– 排队系统中的平均并发任务数

λ– 每单位时间到达排队系统的平均任务数

W– 任务在排队系统中花费的平均服务时间

隔板模式更多地是关于控制L以防止资源耗尽。这可以通过使用来完成：

• 有界队列+线程池
• 信号量

即使是非阻塞应用程序也需要您可能想要限制的每个并发任务的资源。信号量可以帮助限制并发任务的数量。

RateLimiter 模式是关于控制λ的，TimeLimiter 模式是关于控制允许任务花费的最长时间。

自适应 Bulkhead 甚至可以取代 RateLimiters。看看Jon Moore 的精彩演讲“Stop Rate Limiting！Capacity Management Done Right”

我们目前正在 Resilience4j 中开发一个 AdaptiveBulkhead，它可以动态调整任务的并发限制。该实现可与 TCP 拥塞控制算法相媲美，后者使用加法增加/乘法减少 (AIMD) 方案来动态调整拥塞窗口。但是 AdaptiveBulkhead 当然与协议无关。