我正在使用分布式系统的Birman-Schiper-Stephenson协议，目前的假设是任何节点的对等集都不会改变。根据协议规定，已经从节点的因果顺序出现的消息必须放在“延迟队列”中。我的问题在于延迟队列的组织，我们必须在消息中实现某种顺序。在决定命令之后，我们将不得不制定一个“唤醒”协议，该协议将在修改当前时间戳之后有效地搜索队列，以查明是否可以“唤醒”并接受其中一个延迟消息。
我在考虑根据它们的向量时间戳与该节点的时间戳的差异点将延迟的消息分离到bin中。但是箱子的数量可能非常大，维持它们效率不高。
请为这样的队列建议一些设计。
答案 0 :(得分：0)
抱歉延迟 - 直到现在才看到你的问题。无论如何，如果你看一下Isis2.codeplex.com，你会发现在Isis2中，我有一个causalsend实现，采用了我们在BSS论文中描述的相同的向量时间戳方案。我所做的是将我的消息按部分顺序保存，按VT排序，然后当发送时，我可以查看延迟的队列并从队列前面发送，直到找到无法交付的内容。它背后的一切都将无法送达。
但实际上这里有一个更深刻的见解：你实际上从不想让延迟消息的队列变得很长。如果队列长于几条消息（比如50或100），则会遇到这样的问题，即队列中的人可能持有相当多的字节数据，并且可能开始分页或以其他方式缓慢运行。因此，它成为一个自我延续的循环，因为他有一个队列，他很可能会丢弃消息，因此排队越来越多。此外，无论如何，从他的角度来看，紧急的事情是恢复那些导致其他人失灵的错过的信息。
这就是你需要一个流量控制方案，其中挂起的异步内容量保持很小。但是一旦你知道队列很小，搜索每一个元素都不会很贵！因此，这个更深层次的观点表明无论如何都需要流量控制，然后由于流量控制（如果你有一个有效的流量控制方案），队列很小，而且由于队列很小，搜索成本也不高！