Meteor 流星，种族条件/序列完整性

潜在问题（一般）：

用户A输入一条聊天信息（使用浏览器/客户端A），该信息立即添加到他的视图中，并发送到服务器。服务器将其发送给用户/客户端B以更新其视图。但与此同时，用户B输入了一条聊天信息，它会立即添加到他的视图中-现在有消息B作为用户B聊天历史记录中的最后一条消息，消息a作为用户a聊天历史记录中的最后一条消息。这在许多用例中都是一个问题，例如，考虑到人们在测验中竞争，谁先发布正确答案是相关的

在Meteor中如何处理这个问题

潜在的解决方案（对于序列完整性至关重要的web应用程序）：

没有即时的客户端视图更新

只需将数据块（这也是一个更新请求）发送到服务器，服务器将其添加到中心模型中，并将其分发到所有客户端（包括创建数据块的用户的客户端）

每个客户端更新其模型和视图，然后向服务器发送一个简短的“我处理了我得到的更新请求”

服务器等待最后一个这样的信号（忽略断开连接的用户）[1]，然后准备好接收下一条数据（下一个更新请求）。如果队列中有项目，请先处理这些项目

这样，无论哪个数据块首先到达服务器，都将获胜（并且在所有客户机上获胜），稍后到达服务器的数据块将在第一个数据块反映到每个客户机后进行处理

（事实上，creator的客户端中的视图更新发生得晚了一点（因为数据首先经过服务器），我想这不是什么大问题。）

[1] （确保始终处理意外断开）

---

Tobi

据我所知，meteor中发生的情况如下（显然取决于执行顺序）：

用户A在客户端上创建消息

A_c

用户A在服务器上创建消息

A_

（这是自动发生的）

用户B在客户端上创建消息

B_c

A_-s

同时分发给用户A和用户B，将A替换为

A_-c

，将B替换为

B_-c

用户B在服务器上创建消息

B\s

B_s

分发给两个用户

所以可能会发生的事情（取决于先发生的是4还是5），是B会看到一点闪烁，而她的消息被分流到a的下面。通过更具体地使用

Meteor.method

s（而不仅仅是使用集合为您创建的隐式方法），可能可以获得更好的解决方案

在任何情况下，偶尔出现奇怪的闪烁（我认为这是一种边缘情况，取决于延迟）都比创建者的视图更新延迟要好得多