sockets - 通讯协议(protocol)

Question

我正在开发由主服务器和工作服务器组成的分布式系统。应该有两种消息:

心跳

Master 获取 worker 的状态并立即响应适当的命令。例如:

1. 从 Worker 到 Master 的消息:“嘿，我有数据 a、b、c”
2. Master 对 Worker 的响应:“没问题，但是扔掉 c - 我们不再需要它了”

参与者以间隔 T 交换此消息。

直接master命令

假设客户要求 master 终止作业 #123。这是对话:

1. Master 给 Worker 的消息:“警报!我们需要终止作业 #123”
2. 从 Worker 到 Master 的消息:“没问题!完成。”

很明显，我们无法预测此消息何时出现。

---

最简单的解决方案是 master 是这两个消息的所有通信的发起者(在心跳的情况下，我们将包含另一个来自 master 的消息以开始交换)。但是让我们假设在 master 端为 N worker 执行所有心跳管理是昂贵的。我们不想浪费我们的资源来保持与工作服务器的多个 tcp 连接，所以我们只有一个。

有解决这个问题的方法吗？

Answer 1

首先，您必须在某处做一些簿记。否则，谁会意识到一个 worker 已经死了？如果您正在构建主/工作系统，那么放置该数据的自然位置是在主服务器上。否则，可能会要求 worker 们在一个长圆圈或随机图表中互相跟踪。如果 worker 注意到他们的责任伙伴不再响应，它可以提醒主人。

同样的事情适用于当前运行的作业列表；谁跟踪那个？它还扩展了 O(n)，所以大概主人也没有空间。将这些数据分给工作人员(例如，通过跟踪他们的责任伙伴应该做的事情)只能到此为止；如果 a 和 b 崩溃了，而 a 是唯一一个照看 b 的人，你就失去了列表在 b 上运行的作业(可能还有应该通知您 b 崩溃的警报)。

对于此类任务，我建议使用分布式共识算法。对于生产，使用别人已经写过的东西；他们可能知道自己在做什么。如果它是出于学习目的，我认为，请查看 raft consensus algorithm .它并不难理解，但仍然突出了分布式系统中的许多复杂性。模拟器是正确理解的黄金。

面对 worker 崩溃时，master/worker 系统永远无法为 n worker 使用少于 O(n) 的资源。根据定义，master 需要控制 worker，这是一个 O(n) 的工作，即使一些 worker 管理其他 worker。另外，如果 master 崩溃了怎么办？