基于 this answer ，看起来 meteor 服务器为每个连接的客户端保留了缓存的内存副本。我的理解是使用它是为了避免在处理客户端上的重叠订阅时发送多个数据副本。
链接答案的相关部分(重点是我的):
The merge box: The job of the merge box is to combine the results (added, changed and removed calls) of all of a client's active publish functions into a single data stream. There is one merge box for each connected client. It holds a complete copy of the client's minimongo cache.
假设这个答案在当前版本的meteor中仍然准确，随着用户数量的增加，这会不会在服务器上造成巨大的内存浪费？
作为一个即兴计算，如果一个应用程序每个客户端有大约 100kB 的缓存，那么 10,000 个并发用户将使用服务器上的 1GB 内存，而 100,000 个用户将使用高达 10GB 的内存!即使每个客户都在查看几乎相同的数据，情况也是如此。一个应用程序使用的数据比每个客户端使用的数据多得多，这似乎是合理的，这会进一步加剧问题。
当前版本的 Meteor 中是否存在此问题？如果是这样，可以使用哪些技术来限制服务器管理所有客户端订阅所需的内存量？
最佳答案
看看阿鲁诺达在他的meteorhacks.com 博客上的这篇文章:
http://meteorhacks.com/making-meteor-500-faster-with-smart-collections.html
其中谈到了他的智能收藏页面:
http://meteorhacks.com/introducing-smart-collections.html
他创建了一个替代的 Collection 堆栈，它成功地实现了速度、效率(内存和 CPU)和可扩展性(您可以在帖子中看到图形比较)的目标。不可否认，在他的测试中，两种 Collection 类型的 RAM 使用都疏忽了，尽管他实现事物的方式与您提到的用例类型应该有非常明显的区别。
另外，你可以在这篇关于meteor-core的帖子中看到:
https://groups.google.com/d/msg/meteor-core/jG1KLObX1bM/39aP4kxqWZUJ
Meteor 开发人员知道他的工作，并正在合作实现 Meteor 本身的一些改进(但在那之前他的智能包工作得很好)。
重要提示!智能集合依赖于对 Mongo Oplog 的访问。如果您在自己的机器或托管基础架构上运行，这很容易。如果您使用的是基于云的数据库，则此选项可能不可用，或者如果可用，将比较小的软件包花费更多。
关于数千并发用户的 meteor 服务器端内存使用情况，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17073263/