14/WMP

14/WMP

工作者-管理者协议

工作者-管理者协议是请求-回复模式的通用化，允许许多工作者与许多管理者（服务器）通过中间设备和自定义负载均衡进行通信。本文是对协议的简要描述，缺少细节且不完整。我将尽力尽快完成它并提供一个参考实现。

许可

版权所有 (c) 2011 Brugeman Artur

本规范是自由软件；您可以根据自由软件基金会发布的 GNU 通用公共许可证的条款重新分发和/或修改它；可以是许可证的第 3 版，也可以是（由您选择）任何更高版本。

分发本规范是希望它会有用，但没有任何担保；甚至不包含对适销性或特定用途适用性的默示担保。有关更多详细信息，请参阅 GNU 通用公共许可证。

您应该随本程序一起收到了 GNU 通用公共许可证的副本；如果没有，请参阅 https://gnu.ac.cn/licenses。

变更流程

本规范是一个自由开放的标准（参见“自由开放标准定义"），并受数字标准组织（Digital Standards Organization）的共识导向规范系统（COSS）管辖（参见“共识导向规范系统"）。

语言

文档中的关键词“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”应按照 RFC 2119 中描述的进行解释（参见“RFC 中用于指示要求级别的关键词"）。

目标

该协议的目的是为了实现

  1. 工作者和管理者之间的多对多通信。
  2. 每个工作者同时处理多个任务。
  3. 基于工作者空闲状态的可扩展负载均衡。
  4. 对中间设备的支持。

架构

协议

该协议的灵感来自 gearman（参见“Gearman 项目"），对熟悉它的人来说。有两种类型的对等方：工作者（接收请求并发送响应）和管理者（发送请求并接收响应）。

对等方交换消息。每条消息包含一个命令、可扩展的附加信息（“头部”，可能包括路由路径、管理者身份、角色等）以及可选的负载。共有 6 种命令，其中 3 种由管理者发送，3 种由工作者发送。

管理者不了解他们的工作者，他们通过绑定套接字并等待接收消息来启动。工作者了解他们的管理者（端点等），他们通过连接到每个管理者并发起消息交换来启动。

方案

 W               M
   --- READY -->   Worker is ready
   <-- WAKE  ---   Have job for you
   --- GIVE  -->   Give me some job
   <-- TAKE  ---   Take the job
       or
   <-- NO    ---   No job for you
   --- DONE  -->   Job is done

描述

  1. 为了获取任务，工作者向其所有管理者发送 READY 命令。
  2. 管理者收到 READY 后，会记住一个可用工作者（到工作者的路由路径），直到有任务可用。如果收到另一个带有已记住路由路径的 READY 消息，则该消息将被忽略。
  3. 当有任务可用时，管理者向所有相应的工作者发送 WAKE 命令（对应关系由自定义负载均衡方案定义，或者在最简单的情况下可以是“任意工作者”）。
  4. 工作者收到 WAKE 命令后，检查是否可以执行该任务。如果工作者正忙（没有可用资源），则 WAKE 消息将被忽略。否则，处理该任务所需的部分工作者资源将被“锁定”（标记为由特定管理者请求），并向请求的管理者发送 GIVE 命令。
  5. 管理者收到 GIVE 后，检查是否有任务分配给该工作者。如果有任务，则向请求的工作者发送包含 TAKE 命令和任务负载的消息。如果没有任务分配给该工作者（任务已分配给其他工作者），则向请求的工作者发送 NO 命令。
  6. 当工作者收到 GIVE 命令后，它处理任务，然后“解锁”被该任务管理者占用的资源，并回复 DONE 命令，将结果作为负载。
  7. 如果工作者收到 NO 命令，它只需“解锁”被该任务管理者占用的资源。

负载均衡

如上文第 3 段所述，该协议提供了基于工作者可用性（空闲状态）的负载均衡。工作者可以通过向管理者提供附加信息（例如“角色”）来扩展此基础，以便管理者利用该信息确定每个任务的合适工作者。此类功能是应用程序特定的，超出本协议的范围。

多任务

为了让单个工作者处理多个任务，工作者在收到任务（TAKE 消息）后、但在处理任务之前，应立即发送 READY 消息。管理者会将每个 READY 命令视为独立的任务请求，并会给工作者分配另一个任务。

异常情况

为了防止工作者的资源被无限期锁定，设置了超时机制。如果超时，工作者将解锁其资源。这种情况很少见，因为管理者通常会回复 TAKE 或 NO。

工作者可以在一段时间后重试发送 READY 命令，以防管理者遗忘了之前的请求。最好采用一些回退策略，避免使用 READY 命令造成网络拥塞。

中间设备

中间设备在一侧充当工作者，在另一侧充当管理者。设备被分配一个列表，其中包含其工作者端应连接到的管理者。规则

  1. 管理者端收到的 READY 消息（对话中的初始消息）由工作者端转发给所有列表中的管理者。
  2. 来自双方的所有其他消息都使用路由路径信息转发到下一个对等方。

终端节点必须知道与其通信的对等方的身份。为了在中间设备存在的情况下实现这一点，终端节点身份取自路由路径（路径的起点），但有一个例外（参见路由，第 2 段）。

路由

为了支持路由，当消息在终端之间传递时，所有中间对等方都会添加路由信息，以便消息可以沿相同路径返回。

与其他命令不同，TAKE 命令在发送时会指定管理者的身份。此扩展允许管理者转发从其他地方接收到的任务请求，因为如果管理者处于路径中间，则无法从路由路径确定管理者的身份。工作者会遵循指定的管理者身份，并使用该身份而非路由路径。

可靠性

所有可靠性问题，例如任务超时、任务请求和响应的去重、重试等，都在应用层处理。该协议的目的是在带有设备的、多对多的请求-回复场景中实现负载均衡，而不是提供任何形式的可靠性。

扩展

为了扩展协议提供的功能，可以引入另外两个命令。STATUS - 由工作者发送，用于指示任务状态。以及 CANCEL 命令 - 由管理者发送，用于通知工作者不再期望任务结果，并且可以取消任务处理。