我正在阅读 Akka 中的 dispatchers，我了解到它用于隔板目的。什么是计算机科学中的隔板？
【问题讨论】：
标签： design-patterns akka computer-science dispatcher
引用 Jonas Bonér 在 2016 年 4 月提供的 keynote address 的话：
隔离故障——能够控制和管理故障而不用级联——这种模式有时被称为Bulkheading。
几个世纪以来，在造船业中，隔板一直被用作将船舶分隔成独立的水密隔间的一种方式，这样即使有几个隔间充满水，泄漏也不会扩散，船舶可以继续运行并到达目的地。
弹性——从故障中恢复的能力——取决于对故障的划分和遏制，只有摆脱同步通信的强耦合才能实现。
在 Akka 系统中，通常通过调度程序调整来实现隔板，正如 Jamie Allen 在 blog post 中所描述的那样，以下是其中的摘录：
我在 Akka 用户中遇到的最大问题之一是如何使用调度程序创建故障区域并防止应用程序的一个部分发生故障而影响另一部分。这有时被称为隔板模式....
将参与者划分为故障区的关键是确定他们的风险状况。是不是特别危险的任务，比如网络IO？是不是需要阻塞的任务，比如数据库访问？在这些情况下，您希望将这些参与者及其线程与从事危险性较小的工作的参与者隔离开来。如果某个线程发生某些事情导致它完全死亡并且无法从池中使用，那么隔离是您唯一的保护措施，这样不相关的参与者就不会受到资源减少的影响。
您可能还想通过分析识别繁重计算的区域，并使用路由器（没有共享邮箱，因此没有工作窃取）和 BalancingDispatcher（所有“路由”的一个邮箱，因此偷工减料）。对于您分配给路由器的那些任务，您可能还希望它们在自己的调度程序上运行，这样密集的计算任务就不会让等待线程执行其工作的其他参与者饿死。
Akka 文档还描述了the use of dispatchers to manage blocking。
除了调优调度器，在 Akka 中还可以使用circuit breakers 来实现隔板。断路器是防止级联故障的可配置机制。文档给出了以下示例：
例如，我们有一个 Web 应用程序与远程第三方 Web 服务交互。 假设第三方已经超卖了他们的容量，他们的数据库在负载下崩溃了。 假设数据库出现故障，需要很长时间才能将错误返回给第三方 Web 服务。这反过来又使调用在很长一段时间后失败。回到我们的 Web 应用程序，用户已经注意到他们的表单提交似乎要花费更长的时间。好吧，用户会做他们知道要做的事情，即使用刷新按钮，向他们已经运行的请求添加更多请求。这最终导致 Web 应用程序由于资源耗尽而失败。这将影响所有用户，即使是那些不使用依赖此第三方网络服务的功能的用户。
在 Web 服务调用中引入断路器会导致请求开始快速失败，让用户知道出现问题并且他们不需要刷新他们的请求。这也将故障行为仅限于那些使用依赖于第三方的功能的用户，其他用户不再受到影响，因为没有资源耗尽。断路器还可以让精明的开发人员标记网站中使用该功能的部分不可用，或者在断路器打开时适当显示一些缓存的内容。
【讨论】：
解决方案：用于阻塞操作的专用调度程序 隔离阻塞行为以使其不影响系统其余部分的最有效方法之一是为所有这些阻塞操作准备和使用专用调度程序。这种技术通常被称为“bulk-heading”或简称为“isolatedblocking”。
【讨论】：