0

潜在问题（一般）：

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

这在 Meteor 中是如何处理的？

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

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

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

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

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

这样，首先到达服务器的数据块将获胜（并在所有客户端上获胜），稍后到达服务器的数据块将在第一个数据块反映在每个客户端之后处理。

（事实上​​，创建者客户端中的视图更新发生得稍晚一点（因为数据首先通过服务器）我猜这不是一个大问题。）

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

托比

4

1 回答 1

0

据我了解，流星中发生的事情将是这样的（显然取决于执行顺序）：

  1. 用户 AA_c在客户端创建消息
  2. 用户 AA_s在服务器上创建消息（这会自动发生）
  3. 用户 BB_c在客户端创建消息
  4. A_s分发给用户 A 和用户 B，替换A_c为 A 和B_cB。
  5. 用户 BB_s在服务器上创建消息
  6. B_s分发给两个用户。

所以可能会发生什么（取决于是先发生 4 还是 5），当 B 的消息被分流到 A 的下方时，B 会看到一点点闪烁。Meteor.method通过更具体地使用s （而不是仅仅使用集合为您创建的隐式），可能会获得更好的解决方案。

恕我直言，偶尔出现奇怪的闪烁（我认为这是一种边缘情况，取决于延迟）比在每种情况下都为创建者的视图更新滞后更好的解决方案。

于 2012-08-21T04:01:16.927 回答