Meteor 发布与订阅.pdfVIP

Meteor 发布和订阅 发布和订阅 发布 （Publication ）和订阅 （Subscription ）是 Meteor 的最基本最重要的概念之⼀，但 是如果你是刚刚开始接触 Meteor 的话，也是有 难度的。 这已经导致不少误解，⽐如认为 Meteor 是不安全的，或者说 Meteor 应⽤⽆法处理⼤ 量数据等等。 ⼈们起初会感觉这 概念很迷惑很⼤程度上是因为 Meteor 像变魔法⼀样替你做了很 多事⼉。尽管这 魔法最终看起来很有效，但是它们掩盖了后台真正做的⼯作 （好像 魔术⼀样）。所以让我们剥去魔法的外⾐来看看究竟发⽣了什么。 过去的⽇⼦ ⾸先，让我们回顾⼀下20 11年之前，当 Meteor 还没有诞⽣的时候的⽼⽇⼦。⽐如说 我们要建⽴⼀个简单的 Rails app 。当⽤户来我们的站点，客户端 （举例说浏览器）向 我们的服务器端的 app 发送请求。 App 的第⼀个任务就是搞清楚这个客户请求什么数据。这个可能是搜索结果的第12 页、玛丽的⽤户信息、鲍勃的最新20条微博，等等等等。 你可以想想成为⼀个书店的 伙计在书架之间帮你寻找你要的书。 当正确的数据被找到，这个 App 的下⼀个任务就是把数据转换成好看的，⼈类可读的 HTML 格式 （对于 API ⽽⾔是 JSON 串）。 ⽤书店来举例，那就相当于是把你刚买的书包好，然后装⼊⼀个漂亮的袋⼦。这就是 著名的 MVC （模型 视图控制器）模式中的视图部分。 最终，App 把 HTML 代码送到客户端。这个 App 的任务也就交差了。它可以去买瓶 啤酒然后等着下⼀个请求。 Meteor 的⽅式 让我们看看 Meteor 相对之下是多么的特别。正如我们看到的，Meteor 的关键性创新 在于 Rails 程序只跑在服务器上，⽽⼀个 Meteor App 还包括在客户端 （浏览器）上运 ⾏的客户端组件。 推送数据库⼦集到客户端 这就相当于书店的伙计不仅仅在书店⾥帮你找书，还跟你回家，每天晚上读给你听 （这听起来怪怪的）。 这种架构可以让 Meteor 做更多很酷的事情，其中⼀件主要的就是 Metoer 变得数据库 ⽆处不在。简单说，Meteor 把你的数据拿出⼀部分⼦集复制到客户端。 这样后两个主要结果：第⼀，服务器不再发送 HTML 代码到客户端，⽽是发送真实的 原始数据，让客户端决定如何处理线传数据。第⼆，你可以不必等待服务器传回数 据，⽽是⽴即访问甚⾄修 数据 （延迟补偿 latency compensation ）。 发布 ⼀个 App 的数据库可能⽤上万条数据，其中⼀ 还可能是私⽤和保密敏感数据。显⽽ 易见我们不能简单地把数据库镜像到客户端去，⽆论是安全原因还是扩展性原因。 所以我们需要告诉 Meteor 那 数据⼦集是需要送到客户端，我们将⽤发布功能来做 这个事⼉。 让我们来回到 Microscope 。这⾥是我们 App 数据库中的所有帖⼦： 数据库中的所有帖⼦数据 尽管实际上不存在但是我们还是假设我们的帖⼦中有⼏条因为⾔语不当被打了特殊标 记的。我们需要把他们留在数据库中但是不希望让⽤户看到 （发送去客户端）。 我们第⼀个任务就是告诉 Meteor 那 数据我们要发送去客户端。我们告诉 Meteor 我 们只发布没有打标记的帖⼦。 排除做过标记的帖⼦ 这⾥是对应的代码，在服务器端代码中。 // 在服务器端 Meteor.publish(posts, function() { return Posts.find({flagged: false}); }); 这就保证客户端⽆论如何也⽆法看到打了标记的帖⼦了。这就是 Meteor App 如何做到 安全性的：保证只发布你让这个当前⽤户看到的数据。 DDP 基本上我们可以把发布/订阅模式想象成为⼀个漏⽃，从服务器端 （数据源）过滤数据 传送到客户端 （⽬标）。 这个漏⽃的专属协议叫做 DDP （分布式数据协议 Distributed Data Protocol 的缩写）。 如果想了解 DDP 的更多细节，可以通过看 Matt DeBergalis （Meteor 创始⼈之⼀）在 Real time ⼤会上的讲演视频，或者来⾃ Chris Mather 的这个截屏视频，来学习关于这 个概念更多的细节。 订阅 就算是我们想把打了标记的帖⼦也发送给客户端，我们也不能把成千上万的帖⼦⼀股 脑都发出去。我们需要⼀个机制让客户端来确