我即将设计一个基于高速公路的系统。我经常遇到以下模式：
- 客户端可以通过 RPC 主题请求完整状态 - 例如，投票示例中的所有投票
- 此状态的更新由服务器发布 - 例如特定主题的更改投票
- 客户端通过结合完整状态和更新来跟踪当前状态。
问题如下：
由于高速公路的异步特性，在查询状态和发布更改之间存在潜在的竞争。
虽然在服务器端计算状态，但可能已经将更新发送到客户端。一旦客户端收到完整的状态，它就不再是最新的了。它必须使用较早收到的更新进行修补。
不知何故，我觉得这是一个普遍的问题。是否有一些关于如何处理这种情况的最佳实践？
我正在考虑这样的事情：
- 客户端首先订阅更新主题，然后才进行 RPC 调用。
- 服务器发送的所有数据都必须带有时间戳。
- 如果在 RPC 调用返回之前接收到更新，则将其保存。
- 一旦 RPC 调用到达，客户端会使用所有接收到的更新来修补状态，这些更新具有更新的时间戳。
这有意义吗？还是我错过了一些明显的东西？
我稍微修改了横杆投票示例以显示问题。
查询当前投票的 RPC 调用被人为延迟 5 秒。在收到状态之前打开 web 应用程序并提交投票时，一旦处理投票并收到更新，很快就会看到正确的投票计数。
最终延迟状态到达 - 并显示过时的投票计数。