设计模式征求意见：推模型v.s.拉模型

Question

我的应用程序有几个工作人员（作为不同的进程处理不同的事情）和一些资源（工作单位）。不同的工人需要处理所有工作单位。例如，我有像W1，W2和W3这样的工人，工作单位U1和U2。然后W1需要处理U1和U2，与W2和W3相同。限制是不同的工人不能同时在同一个工作单位工作。

我有两个设计，想要寻求哪个更好的建议。

1. 推送模型：使用中央作业调度程序将工作单位分配给不同的工作人员，以确保不同的工作人员不在同一个工作单位上工作;
2. 拉模型：每个工作人员都会要求中央作业调度程序处理工作单位，而作业调度程序将选择一个适当的工作单位，而其他工作人员不会为该工作单位处理该工作单元。

我想了解每种设计的优缺点。我的一个主要问题是 - 寻找松散耦合的设计（这是我的主要目标之一，但不是唯一的目标）。我不确定推模型或轮询模型是否具有更好的可扩展性（选项1更松散耦合）？

提前谢谢， 乔治

Answer 1

“拉”模型的优点是每个工作人员在本地知道它加载了多少，从而可以管理其负载。

此外，“拉”模型可能更“解耦”，因为“加载”的变量保持在工作者本地，而在“推”模型中，需要通信协议（和开销）来传达此状态

---

想想汽车行业“拉动”模式的成功：它来自传统的“推动”模式，在这种模式下，库存难以跟踪，需要大量反馈到现在成功且无处不在的“拉动”模型。

---

在扩展方面，您可以拥有一个“调度程序”的中间层，可以“轮询”来自上一层的作业。基础工作者现在可以以分区方式与中间层交互。

---

请注意，在任一模型中都需要协调通信协议：协调协议的性质不同。在“推模型”中，需要额外的控制回路来报告/轮询每个工人的“负载系数”。作为一个扩展系统，需要更多带宽，调度程序端更多状态，更多延迟等。

Answer 2

我肯定会使用Pull模型，因为它更容易实现。

我只能想象两个实现：

1. 使用任务集合和许多工作客户端拉模型= 1服务。

2. 使用任务集合推送模型= 1服务，以及活动订阅者列表和许多活动订阅者（工作人员）。

由于Pull模型不必实现全双工服务呼叫既不是订户列表，也更简单。