通過RPC查詢完整狀態與已發布的增量之間的競爭

Question

我將要設計一個基於高速公路的系統。 我經常遇到以下模式：

• 客戶可以通過RPC主題請求完整狀態-例如，表決示例中的所有表決
• 服務器會發布對此狀態的更新-例如，更改特定主題的投票
• 客戶端通過結合完整狀態和更新來跟蹤當前狀態。

問題如下：
由於高速公路的異步特性，在查詢狀態和發布更改之間存在潛在的競爭。
在服務器端計算狀態后，可能已將更新發送到客戶端。 客戶端收到完整狀態后，它就不再是最新狀態。 必須使用先前收到的更新對其進行修補。

不知何故，我覺得這是一個普遍的問題。 關於如何處理這種情況，是否有一些最佳做法？

我正在考慮這樣的事情：

• 客戶端首先訂閱更新主題，然后再進行RPC調用。
• 服務器發送的所有數據都必須加上時間戳。
• 如果在RPC調用返回之前收到更新，則將其保存。
• 一旦RPC調用到達，客戶端就會使用所有具有新時間戳的更新來修補狀態。

這有意義嗎？ 還是我缺少明顯的東西？

我稍微修改了橫杠投票示例以顯示問題。
查詢當前選票的RPC調用被人為地延遲了5秒。 當打開Web應用並在收到狀態前提交投票時，一旦處理了投票並收到了更新，不久就可以看到正確的投票計數。
最終，延遲狀態到達-並顯示過期的投票計數。

Answer 1

干凈的解決方案是Crossbar.io中的一個新功能（ 尚未記錄的功能 ：事件保留。

此選項為訂閱者提供第一個當前訂閱事件之前的單個保留事件。 保留的事件由發布者選擇。 如果發布者選擇了每個事件，則此功能將為您提供上次發布狀態。

在https://github.com/crossbario/autobahn-python/tree/master/examples/twisted/wamp/pubsub/retained中有一個示例

（除了Autobahn | Python之外，不確定是否支持庫。）

否則：您可以在通話前使用訂閱模式以及使用時間戳。