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