第十一章 Meteor 延时补偿.pdf

Meteor 延时补偿 延时补偿 在上⼀章，我们介绍了 Meteor 的⼀个新概念：内置⽅法。 Meteor 的内置⽅法是⼀种在服务器上执⾏⼀系列命 的结构化⽅法。在⽰例中，我们 使⽤内置⽅法是为了确保新帖⼦是通过作者的姓名和 ID ，以及当前服务器时间去标 记。 然⽽，如果 Meteor ⽤最基本的⽅式去执⾏内置⽅法，我们会注意到⼀些问题。想⼀ 想下⾯事件的序列 （注：为演⽰⽅便，时间戳值是随机的⽣成的）： +0ms: ⽤户单击提交按钮，浏览器触发内置⽅法的调⽤。 +200ms: 服务器更改 Mongo 数据库。 +500ms: 客户端接收到这些变化，并更新页⾯反映更改结果。 如果这是 Meteor 的操作⽅式，它会有⼀个很短的时间差去看到这样的执⾏操作的结 果 （延时的多少会取决于你的服务器性能）。但我们不可能让这些情况出现在 Web 应⽤程序中 ！ 延迟补偿 为了避免这个问题，Meteor 引⼊了⼀个叫做延迟补偿 （Latency Compensation ）的概 念。如果我们把 post ⽅法的定义放在 collections/ ⽬录下。这意味着它在服务 端和客户端上都存在，⽽且是同时运⾏ ！ 当你使⽤内置⽅法的时候，客户端会发送请求到服务器去调⽤，同时还模仿服务器内 置⽅法去操作本地数据库集合。所以现在我们的⼯作流程是： +0ms: ⽤户单击提交按钮，浏览器触发内置⽅法的调⽤。 +0ms: 客户端模仿内置⽅法操作本地的数据集合和以及通过更改页⾯来反映这 ⼀变化。 +200ms: 服务器更改 Mongo 数据库。 +500ms: 客户端接收这些更改并取消刚刚的模仿操作，根据服务器的更改覆盖 它们 （通常是相同的）。页⾯的变化反映了这⼀过程。 这样⽤户就会⽴刻看到变化。服务器的响应返回⼀段时间后，根据服务器数据库发送 过来的更改请求，本地数据库可能会或可能不会有明显的改变。因此，我们应该学会 确保本地数据尽可能地与服务器数据库保持⼀致。 观察延迟补偿 我们可以对 post 内置⽅法的调⽤稍作改动。为此，我们将会通过 npm 包 futures ，使⽤⼀些⾼级的编程⽅式去把延迟对象放到我们的内置⽅法调⽤⾥⾯。 我们将使⽤ isServer 去问 Meteor 现在所调⽤的内置⽅法是在客户端被调⽤ （作为 ⼀个存根 Stub ）或是在服务器端。这个存根 stub 是模仿内置⽅法在客户端运⾏的模拟 ⽅法，⽽“真正的” 内置⽅法是在服务器上运⾏的。 所以我们会询问 Meteor 这部分代码是否在服务器端执⾏。如果是，我们会在帖⼦的 标题后⾯添加 (server) 字符串。如果不是，我们将添加 (client) 字符串： Posts = new Mongo.Collection(posts); Meteor.methods({ post nsert: function(postAttributes) { check(this.user d, String); check(postAttributes, { title: String, url: String }); if (Meteor.isServer) { postAttributes.title += (server); // wait for 5 seconds Meteor._sleepForMs(5000); } else { postAttributes.title += (client); } var postWithSameLink = Posts.findOne({url: postAttributes.url if (postWithSameLink) { return { postExists: true, _id: postWithSameLink._id } } var user = Meteor.user(); var post = _.extend(postAttributes, { user d: user._id, author: user.username, submitted: new