什么是 Meteor 并发模型？答案

【问题标题】：What is the Meteor concurrency model?什么是 Meteor 并发模型？
【发布时间】：2013-08-12 18:55:03
【问题描述】：

我正在为 Meteor 应用程序编写服务器端逻辑，该应用程序必须更新内存状态以响应来自客户端的请求。此应用程序需要强大的并发保证 - 特别是，我想确保一次只执行一个更新。

我试图弄清楚 Meteor 的并发模型是否支持这一点。文档提到 Meteor 是多线程的（这将是一个问题），但是在搜索之后，我得到的印象是 Meteor 实际上使用了光纤（显式调度的线程）。如果这是真的，那么只要我的代码中需要以原子方式运行的部分不进行任何 Meteor 调用（这涉及 IO 并因此产生执行锁），我就是安全的。

是这样吗？在哪里可以找到有关 Meteor 并发模型的更多信息？

【问题讨论】：

我认为你应该自己为你的内存存储实现锁，或者你可以使用 mongo 原子操作。
如果有帮助，纤维库的文档在 [这里][1] [1]：github.com/laverdet/node-fibers
@Denis 如果我可以实现内存锁，因为非 IO、非屈服操作是原子的，那么我什至不需要它们用于这个应用程序。无论如何，我想知道 Meteor 中的并发如何为未来的信息工作。这些东西应该在某个地方清楚地记录下来；不是。我可能最终会浏览 Meteor 源代码。

标签： javascript multithreading concurrency meteor fibers

【解决方案1】：

好的，我查看了 Meteor 的源代码，事情是这样的：

1) 在服务器端，Meteor 专门使用纤程来处理并发。纤维就像线程，除了必须显式地产生上下文。这使得对并发性的推理更容易，但（潜在的）代价是某些纤程会饿死其他纤程。

2) 所有对 Meteor.call、Meteor.setInterval 和任何 Collection 操作的调用都包装在纤维中。这意味着所有这些调用都会产生上下文。

3) 此外，任何使用 fiber/futures 模块都会产生收益。

这种结构的结果是，如果你想编写原子操作，只需避免在你想成为原子的代码块中访问 Meteor 框架提供的对象。如果这个块真的需要（比如说）一个数据库访问，那么你可以毫无困难地实现内存锁，但是对于我的应用程序来说，这些知识就足够了。我的核心更新函数只需要调用它需要从 Mongo 读取的所有文档。

【讨论】：

【解决方案2】：

来自流星文档：

在 Meteor 中，您的服务器代码在每个请求中运行在一个线程中，而不是在 Node 典型的异步回调风格中。我们发现线性执行模型更适合 Meteor 中的典型服务器代码应用。

http://docs.meteor.com/#structuringyourapp

有人知道这对性能的影响吗？

【讨论】：