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

Question

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

• 客户端可以通过RPC主题请求完整状态 - 例如，投票示例中的所有投票
• 此状态的更新由服务器发布 - 例如，特定主题的更改投票
• 客户端通过组合完整状态和更新来跟踪当前状态。

问题如下：
由于高速公路的异步性质，在询问国家和公布的变更之间存在潜在的竞争 虽然在服务器端计算状态，但可能已经将更新发送到客户端。 一旦客户端收到完整状态，它就不再是最新的。必须使用之前收到的更新修补它。

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

我正在考虑这样的事情：

• 客户端首先订阅更新主题，然后才进行RPC调用。
• 服务器发送的所有数据都必须加上时间戳。
• 如果在RPC调用返回之前收到更新，则会保存。
• 一旦RPC调用到达，客户端将修补状态，所有收到的更新都有一个更新的时间戳。

这有意义吗？或者我错过了一些明显的东西？

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

Answer 1

干净的解决方案是Crossbar.io中的一个新的not yet文档feature：事件保留。

此选项在第一个当前订阅事件之前为订阅者提供单个保留事件。保留的事件由发布者选择。如果发布者选择了每个事件，则此功能会为您提供上次发布的状态。

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

就是一个例子

（不确定除了Autobahn | Python之外的库中的支持。）

否则：您在调用之前订阅的模式是有意义的，以及使用时间戳。