基于this answer，看起来流星服务器为每个连接的客户端保留缓存的内存副本。我的理解是它被用来避免在处理客户端上的重叠订阅时发送多个数据副本。
相关答案的相关部分（重点是我的）：
合并框：合并框的作用是将所有客户端的活动发布功能的结果（添加，更改和删除的调用）组合到单个数据流中。每个连接的客户端都有一个合并框 。它拥有客户端的最小缓存的完整副本。
假设在当前版本的流星中答案仍然准确，那么随着用户数量的增加，这不会在服务器上造成巨大的内存浪费吗？
作为袖手旁观的计算，如果一个应用程序每个客户端有大约100kB的缓存，那么10,000个并发用户将在服务器上消耗1GB内存，而100,000个用户则高达10GB！即使每个客户端都在查看几乎相同的数据，情况也是如此。应用程序使用比每个客户端更多的数据似乎是合理的，这将进一步加剧问题。
当前版本的Meteor中是否存在此问题？如果是这样，可以使用哪些技术来限制服务器管理所有客户端订阅所需的内存量？
答案 0 :(得分：5)
看看Arunoda在他的meteorhacks.com博客上的这篇文章：
http://meteorhacks.com/making-meteor-500-faster-with-smart-collections.html
谈论他的智能收藏页面：
http://meteorhacks.com/introducing-smart-collections.html
他创建了一个替代的Collection堆栈，它已经成功实现了速度，效率（内存和CPU）和可伸缩性的目标（你可以在帖子中看到一个图形比较）。不可否认，在他的测试中，RAM的使用对于两种Collection类型都是疏忽的，尽管他在那里实现的方式应该与你提到的用例类型有非常明显的区别。
另外，你可以在这篇关于meteor-core的帖子中看到：
https://groups.google.com/d/msg/meteor-core/jG1KLObX1bM/39aP4kxqWZUJ
流星开发人员了解他的工作，并正在合作实施Meteor本身的一些改进（但在此之前，他的智能包非常有用）。
重要提示！智能收藏依赖于对Mongo Oplog的访问。如果您在自己的计算机或托管基础架构上运行，这很容易。如果您使用的是基于云的数据库，则此选项可能不可用，或者如果使用此选项，将比较小的软件包花费更多。