通过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之外，不确定是否支持库。）

否则：您可以在通话前使用订阅模式以及使用时间戳。