水平扩展聊天记录工作者

Question

我已经考虑了很多,但无法想出一个我很满意的解决方案.

基本上这就是问题:记录100k + Chats(有些慢,有些更快)进入cassandra.因此保存userId,channelId,timestamp和消息.

Cassandra已经支持水平扩展,我在这里没有问题.

现在,我读取这些聊天的软件通过TCP(IRC)完成.对于顶级1k通道,通常会有300条消息/秒,而单个IRC连接无法处理我的实验.

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

现在,我将如何最好地动态分享工人之间加入的当前渠道.我想避免拥有主人或控制点.还应该很容易添加更多的工人,然后减少其他工人的负担.

有关这种行为的好文章吗？也许已经定义了好的概念或协议？就像我说的,我想避免另一个中央控制点,所以没有rabbitmq,redis或其他什么.

编辑:我已经研究过像Raft Consensus Algorithm这样的东西了,但是我认为这没有意义,因为我不希望我的客户就共享状态达成一致,而是将它们之间的状态"平等地"分开.

Answer 1

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

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

因此（琐碎的部分）通道将具有 ID 和分配的工作人员 ID，加上在可选的冗余情况下 - 所需的工作人员数量（2 个或您想要处理此聊天的任意数量的工作人员）。工作人员在将自己分配给频道之前会​​检查是否已经有足够的受让人。如果是这样，将继续下一个频道。如果没有，则将其自身分配给该通道。这是选项之一（或者，您可以让工作人员持有通道 ID，但由于冗余很少见，这种方式似乎更简单）。工作人员可以处理的通道是有限的，并且不会尝试通过分配更多通道来超出该限制。

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

这需要为工作人员分配不同的优先级，这可以在生成它们时轻松实现，只需将每个工作人员设置为下一个连续编号（最旧的具有最高优先级，或者如果您担心老的、可能垂死的工作人员占用了所有工作人员，则为 vv）负载，并且更喜欢新的在仍然新鲜的情况下承担更多）。更详细地说，这也可以通过使用 Cassandra轻量级事务来完成，如此处答案之一（AlonL 的答案）中所述。只要有几个（您提到的〜4个）工作人员，无论哪种方式都应该可以工作，并且担心其他答案中提到的扩展，对于一些整数优先级来说没什么大不了的。此外，要求工作人员在初始化时自行分配随机 32 位整数优先级而不是顺序编号分配，实际上不会发生冲突，因此“直到没有冲突”循环应该在第一次迭代时退出（这将使第二次迭代很少需要显式测试的代码路径）。

诀窍基本上是限制需要同步的数据量，并将监管负担转移到工作人员身上。不需要共识算法，因为没有太多复杂性，而且我们不会与大量潜在的欺诈工人打交道，试图在更资深的同行之前获得任务。

我应该提到的唯一问题是，如果通道离线，可能会存在隐式工作人员轮换，这会使工作人员停止处理。下次频道上线时，您将获得不同的工作人员分配。