我已经考虑了很多，但是无法提出我满意的解决方案。
基本上这是问题所在：将100k +聊天记录（速度较慢，速度较快）登录到cassandra。因此，请保存userId，channelId，时间戳和消息。
Cassandra已经支持开箱即用的水平缩放，在这里我没有问题。
现在，我的软件可以通过TCP（IRC）读取这些聊天记录。在我的实验中，前1k频道通常每秒传输300条消息，而1条IRC连接无法处理我的实验。
我现在要构建的是记录器的多个实例（使用Docker / Kubernetes），并在这些实例之间共享负载。因此，理想情况下，如果我有4个工作人员并且进行1000次聊天（例如）。他们每个都会加入至少250个频道。我说至少是因为我想要可选的冗余，所以我可以在同一聊天中拥有2个记录器，以确保不会丢失任何消息。 重复没有问题，因为所有邮件都有唯一的ID。
现在，我将如何最好地动态共享工作人员之间加入的当前渠道。我想避免拥有主控点。添加更多的工作人员以减少其他工作人员的负担也应该很容易。
是否有关于这种行为的好文章？也许已经定义了好的概念或协议？就像我说的，我想避免使用另一个中央控制点，所以不要使用rabbitmq，redis或其他东西。
编辑：我已经研究了类似筏共识算法的方法，但是我认为这没有任何意义，因为我不希望我的客户就共享状态达成共识，而是将它们之间的状态“平均地”划分
答案 0 :(得分：3)
在这种情况下，我认为寻找现有算法的描述可能不是很有用：该问题并不复杂且普遍，不足以值得发表。
如上所述，可以通过使用Cassandra本身作为中介程序并在工作人员之间共享聊天频道分配信息来解决该问题。
因此（重要部分）通道将具有ID和已分配的工作人员ID，以及在可选的冗余情况下-所需的工作人员数量（2个或要处理此聊天的任何数量的工作人员）。工作者在将自己分配给渠道之前，将检查是否已经有足够的分配者。如果是这样，将继续下一个频道。如果不是，则将其分配给该通道。这是一种选择（或者，您可以让工作人员持有通道ID，但是由于冗余很少，因此这种方法似乎更简单）。员工将拥有可以处理的渠道限制，并且不会尝试通过分配更多渠道来超过此限制。
现在，我们只需要处理将过多的工作人员分配给同一渠道，超出要求并通过监视所有相同的渠道来耗尽工作人员能力的情况。否则，如果它们一次全部启动，则通道可能分配了比所需数量更多的工作线程。即使在描述的情况下不太可能造成实际问题（仅比要求的冗余多一点），您也可以通过优先考虑工作人员来解决此问题。就像在加拿大雇用学校老师一样，卑诗省以资历为基础-最高级的人首先得到工作，只是在这里这是由工人自己自愿完成的，而不是由学校行政管理。这意味着每个工作人员都必须检查所有分配的渠道，并且如果此时的工作人员数量超过需求，则将检查所有工作人员中优先级是否最低。如果是这样，它将辞职-自行删除并停止处理该频道。
这要求分配工人的不同优先级，这可以通过简单地将每个工人设置为下一个序号来实现（在产生它们时很容易实现（最旧的优先级最高，如果您担心老的，可能垂死的工人在考虑，则选择vv）负担所有的工作量，并希望新的任务在保持新鲜的同时承担更多的任务）。更详细地说，这也可以通过使用答案Lightweight transactions（here之一）中所述的Cassandra one by AlonL来完成。在只有少数几个（您提到的〜4个）工作人员中，任何一种方式都应该工作，而其他答案中提到的关于扩展的担忧对于几个整数优先级来说并没有什么大不了的。同样，除了顺序编号分配外，要求工作人员在初始化时自行分配一个随机的32位整数优先级几乎没有冲突的机会，因此循环“直到没有冲突”应该在第一次迭代时退出（这将导致第二次迭代很少需要显式测试的代码路径。
诀窍基本上是限制需要同步的数据量，并将法规负担加到工人身上。不需要共识算法，因为它没有太多的复杂性，而且我们也没有与大量潜在的欺诈工人打交道，而是试图使工作任务领先于其他高级同事。
我唯一要提到的问题是，如果通道脱机，工作人员可能会轮换工作，这会使工作人员停止处理。下次频道上线时，您将获得其他工作人员分配。