我正在使用分佈式系統的Birman-Schiper-Stephenson協議，目前假設任何節點的對等集都不會改變。正如協議規定的那樣，從節點序列到節點的消息必須放入「延遲隊列」中。我的問題是延遲隊列的組織，我們必須在消息中實現某種順序。在決定訂單後，我們必須制定一個'喚醒'協議，在當前時間戳被修改後有效搜索隊列，以確定是否有一個延遲的消息可以'喚醒'並被接受。高效實現Birman-Schiper-Stephenson（BSS）協議的延遲隊列
我正在考慮根據它們的向量時間戳與此節點的時間戳的差異點將延遲的消息分隔成多個分區。但箱的數量可能非常大，維護它們效率不高。
請爲此類隊列推薦一些設計。
抱歉，延遲 - 直到現在纔看到您的問題。總之，如果你看看Isis2.codeplex.com，你會發現在Isis2中，我有一個causalsend實現，它使用了我們在BSS論文中描述的相同的向量時間戳方案。我所做的是讓我的消息按照部分順序排列，按VT排序，然後當發生傳遞時，我可以查看延遲的隊列並將隊列送到隊列的前端，直到找到不可交付的東西。背後的一切都將無法傳遞。
但實際上這裏有一個更深刻的見解：你實際上從不想讓延遲消息的隊列變得很長。如果隊列比幾條消息（比如說50或100）長，你會遇到這樣的問題：隊列中的人可能持有相當多的字節數據，並可能開始分頁或以其他方式緩慢運行。所以它變成了一個自我延續的循環，因爲他有一個隊列，他很可能會丟掉信息，因此排隊越來越多。此外，從他的角度來看，緊急的事情是恢復導致其他人失靈的錯過消息。
這個加起來就是你需要一個流量控制方案，在這個方案中，待處理異步數據量保持很小。但是一旦你知道隊列很小，搜索每一個元素將不會很昂貴！因此，這種更深層次的觀點認爲流量控制無論如何都是必要的，然後由於流量控制（如果您的流量控制方案可行），隊列很小，而且由於隊列很小，因此搜索不會很昂貴！