docker - 水平扩展聊天日志 worker

Question

我对此想了很多，但无法提出我满意的解决方案。

基本上这是问题所在:将 100k+ 聊天记录(有些慢，有些快)到 cassandra。所以保存 userId、channelId、timestamp 和 message。

Cassandra 已经支持开箱即用的水平缩放，我这里没有问题。

现在我的软件通过 TCP (IRC) 读取这些聊天记录。前 1k 的 channel 通常每秒 300 条消息，而我的实验中 1 个单一的 IRC 连接无法处理。

我现在想要构建的是记录器的多个实例(使用 Docker/Kubernetes)并在它们之间共享负载。所以理想情况下，如果我可能有 4 个 worker 和 1k 个聊天(示例)。他们每个人都会加入至少 250 个 channel 。我说至少是因为我想要可选的冗余，这样我就可以在同一个聊天中拥有 2 个记录器，以确保不会丢失任何消息。重复没有问题，因为所有消息都有唯一的 ID。

现在，我将如何最好地动态共享工作人员之间加入的当前 channel 。我想避免有一个主人或控制点。也应该很容易添加更多的 worker ，然后减少其他 worker 的负担。

有没有关于这种行为的好文章？也许已经定义了好的概念或协议(protocol)？就像我说的，我想避免另一个中央控制点，所以没有 rabbitmq、redis 或其他任何东西。

编辑:我研究过类似 Raft 共识算法的东西，但我认为这没有意义，因为我不希望我的客户就共享状态达成一致，而是“平等地”划分它们之间的状态.

Answer 1

我认为在这种情况下寻找现有算法的描述可能不是很有用:问题并不复杂和通用，不值得发表。

如上所述，问题可以通过使用 Cassandra 本身作为中介并在工作人员之间共享聊天 channel 分配信息来解决。

因此(微不足道的部分) channel 将具有 ID 和分配的工作人员 ID，以及在冗余的可选情况下 - 所需的工作人员数量(2 或您想要处理此聊天的任何数量的工作人员)。 Worker，在将自己分配给 channel 之前会检查是否已经有足够的受让人。如果是这样将继续下一个 channel 。如果不是，则将其分配给 channel 。这是选项之一(或者您可以让工作人员持有 channel ID，但由于冗余很少，这种方式似乎更简单)。 worker 将有他们可以处理的 channel 限制，并且不会通过分配更多 channel 来尝试超过它。

现在我们只需要通过监控所有相同的 channel 来处理将过多的工作人员分配到同一 channel 、超出要求和耗尽工作人员能力的情况。否则，如果它们同时启动， channel 分配的工作人员可能比需要的多。尽管在所描述的情况下不太可能会产生真正的问题(只是比要求的冗余多一点)，但您可以通过优先处理 worker 来解决这个问题。就像在加拿大雇用学校教师一样，BC 是根据资历来完成的 - 最资深的人首先得到工作，除了在这里它是由 worker 自己自愿完成的，而不是由学校管理部门完成。这意味着，每个工作人员都必须检查所有分配给它的 channel ，并且如果此时工作人员数量超过需要，将检查它是否在所有受让人中具有最小的优先级。如果是，它将辞职 - 删除自己并停止处理 channel 。

这需要为 worker 分配不同的优先级，这可以在生成它们时轻松实现，只需将每个设置为下一个序列号(最旧的具有最高优先级，或者如果您担心年老的、可能濒临死亡的 worker 采取承担所有负载，并且希望新的负载在仍然新鲜的时候承担更多)。更详细地说，这也可以通过使用 Cassandra Lightweight transactions 来完成。如答案之一所述 here (one by AlonL)。只要有几个(你提到〜4个)工作人员应该可以工作并且其他答案中提到的缩放问题对于几个整数优先级来说没什么大不了的。此外，要求工作人员在初始化时自行分配一个随机的 32 位整数优先级，而不是顺序号分配，实际上没有发生冲突的机会，因此循环“直到没有冲突”应该在第一次迭代时退出(这将导致第二次迭代很少需要显式测试的代码路径)。

诀窍基本上是限制需要同步的数据量，并将监管负担交给工作人员自己。不需要共识算法，因为没有太多复杂性，而且我们没有与大量潜在欺诈 worker 打交道，试图在更高级的同行之前完成任务。

我应该提到的唯一问题是，如果 channel 脱机导致工作人员停止处理，则可能存在隐式工作人员轮换。下次 channel 上线时，您将获得不同的工作人员分配。