处理通过RPC查询完整状态和发布增量之间的竞争

Question

我即将设计一个基于高速公路的系统。我经常遇到以下模式：

• 客户端可以通过RPC题目要求全额状态 - 例如，中投例子
• 更新这个状态的所有选票是由服务器发布 - 例如更改了特定主题的投票
• 客户通过组合完整状态和更新来跟踪当前状态。

的问题如下：
有查询状态和出版变化之间的潜在的竞争，由于高速公路的异步特性。
虽然在服务器端计算状态，但更新可能已发送到客户端。 一旦客户端收到完整的状态，它不再是最新的。必须使用先前收到的更新进行修补。

不知何故我觉得这是一个常见的问题。 如何处理这种情况是否有一些最佳做法？

我正在考虑是这样的：

• 客户第一订阅更新的主题，只有事后做RPC调用。
• 服务器发送的所有数据都必须加上时间戳。
• 如果在RPC调用返回之前收到更新，它将被保存。
• 一旦RPC调用到达，客户端将为所有接收到的更新添加一个更新的时间戳。

这是否有意义？还是我错过了明显的东西？

I slightly modified the crossbar vote example to show the problem.
用于查询当前投票的RPC调用被人为延迟5秒。在收到状态之前打开Web应用程序并提交投票时，一旦处理了投票并收到更新，很快就会看到正确的投票计数。
最终延迟状态到达 - 并显示过时的投票计数。

Answer 1

的清洁解决方案是新的（在not yet记载Crossbar.io feature：事件保留

此选项为用户提供了第一电流订阅事件之前的单个保持事件保留的事件由选择。 。出版商如果出版商选择每个事件，那么这个功能为您提供与上次公布的状态

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

（不知道除了高速公路在图书馆支持这样的例子|，P ython。）

否则：您的模式与呼叫之前的订阅有意义，以及使用时间戳。