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

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

现在我们只需处理将过多工人分配到同一渠道,超出要求并通过监控所有相同渠道耗尽工人能力的情况.否则,如果他们一次启动,则渠道可能会分配比所需更多的工作人员.即使在描述的情况下不太可能产生真正的问题(只是比请求的冗余多一点),您可以通过优先考虑工作人员来解决这个问题.就像在加拿大雇用学校教师一样,不列颠哥伦比亚省是在资历基础上完成的 – 最高级的人首先得到工作,除了在这里,工人自己而不是学校管理部门自愿完成工作.这意味着,每个工人都必须检查所有已分配的渠道,并且如果此时需要的工人数量超过需要,将检查所有受让人中是否具有最低优先级.如果是,它将辞职 – 删除自己并停止处理频道.

这需要分配工人的不同优先级,这可以通过简单地将每个工具分别设置为下一个序列号(最老的具有最高优先级,或者如果您担心旧的,可能正在死亡的工人占用所有加载,并希望新的,以保持更多,同时仍然新鲜).更精细的是,这也可以通过使用Cassandra Lightweight transactions来完成,如答案here(one by AlonL)之一中所述.只有少数(你提到~4)工作者应该工作,并且在其他答案中提到的关于缩放的问题对于几个整数优先级没有大问题.此外,代替顺序编号分配,要求工作人员在初始化时自动分配随机32位整数优先级几乎没有碰撞的机会,因此循环“直到没有冲突”应该在第一次迭代时退出(这将导致第二次迭代很少需要显式测试的代码路径).

诀窍主要是限制需要同步的数据量,并将监管负担放在工人自己身上.不需要共识算法,因为没有太多的复杂性,我们没有处理大量潜在的欺诈工人,试图在更高级别的同行之前获得任务.

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