design-patterns - 设计模式征求意见 : push model v. s。拉模型

Question

我的应用程序有几个工作人员(作为不同的进程处理不同的事情)和一些资源(工作单元)。不同的 worker 需要在所有工作单元上处理。例如，我有 W1、W2 和 W3 等 worker ，工作单元 U1 和 U2。那么 W1 需要处理 U1 和 U2，与 W2 和 W3 相同。限制是不同的 worker 不能同时在同一个工作单位工作。

我有两种设计，想请教哪一种更好。

推送模型:使用中央作业调度器将工作单元分配给不同的工作人员，以确保不同的工作人员不在同一个工作单元上工作；

拉动模型:每个 worker 都会向一个中央作业调度器请求工作单元来处理，作业调度器会为请求的 worker 选择一个没有被其他 worker 处理的合适的工作单元。

我想知道每种设计的优缺点。我主要关心的一个问题是——找到一个松散耦合的设计(这是我的主要目标之一，但不是唯一的目标)。我不确定 push 模型或 poll 模型是否具有更好的可扩展性(选项 1 更松散耦合)？

提前致谢，
乔治

Answer 1

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

此外，“拉”模型可能更加“解耦”，因为“负载”的变量对工作人员保持本地化，而在“推”模型中，需要通信协议(protocol)(和开销)来传达此状态。

想想汽车行业“拉动”模式的成功:它从传统的“推”模式(库存难以追踪、需要大量反馈)转变为现在成功且无处不在的“拉”模式。

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

请注意，在任一模型中都需要协调通信协议(protocol):这是协调协议(protocol)的性质那不同。在“推模型”中，需要一个额外的控制循环来报告/轮询每个 worker 的“负载因子”。随着系统的扩展，需要更多的带宽，调度程序端的更多状态，更多的延迟等。