基础知识| 线程与反应并发模型

Question

我是反应式编程世界的全新手.我正在寻找Akka演员作为开始的一步.

我对基于线程的并发模型的理解是(例如基于Vanilla Servlet的模型):

1. 对于来自客户端的每个请求,都会生成一个新线程.
2. 这意味着所有底层代码的执行都附加到此线程并以串行方式发生.显然,即使代码的一部分存在瓶颈(远程Web服务调用等),线程也将被阻塞并等待并保持空闲状态.
3. 服务器(容器)具有固定的线程池以容纳最大并发线程数,显然,由于瓶颈,它们将快速运行线程.

我对Reactive并发模型的理解是(例如基于Akka的模型):

1. 所有逻辑不再附加到单个线程并串行执行.
2. 执行流程是被动的(即在消息上,一个actor被触发).

现在我的问题:

假设两个模型中都存在远程Web服务调用的瓶颈.演员模型如何帮助提高CPU /核心利用率？我们不会有同样的问题,即演员中的执行线程被阻止了吗？例如:如果此网络服务呼叫同时阻止了200名参与者？这不意味着目前有200个线程被阻止吗？据我所知,还有其他演员会对其他上游事件做出反应.这是我们所说的更好地利用CPU吗？

在一个Threaded模型中,只是Threadpool的小尺寸问题的原因？

Actor子系统是否有一个线程池来产生一个新的actor并对特定事件作出反应？如果是,那么我们不会有同样的问题吗？

请原谅我这个问题是完全愚蠢的.

Answer 1

“假设瓶颈...”——在响应式模型中，您永远不会使用此类服务​​，而是会异步调用 Web 服务的请求，并为最终响应/错误配置处理程序。\n如果您调用同步服务，您只是重新引入所有批处理模式问题，从而使您的问题更加复杂。如果您无法直接使用它，您将创建一个类似代理的服务作为苍白的模仿（*）。

\n\n

当响应到达时，处理程序可以解开继续操作所需的任何上下文。如果所述上下文相当于 \xe2\x80\x9cstack + registers\xe2\x80\x9d，那么你的框架不是很好，但加载比拥有数百个内核线程上下文来解析消息更好。

\n\n

必须构建响应上下文的形式主义应该引导解决方案远离资源争夺，这在线程模型中很常见。这是一个吸引人的地方，因为如果违反直觉的话，好的线程解决方案和差的反应式解决方案都是可能的。

\n\n

回顾一下：应用程序空间中保存必要信息以继续操作的小型数据结构比内核线程+用户线程+堆栈要好得多。不仅仅是因为它使用的资源更少；但因为它更好地表达了您的解决方案，并允许底层框架/操作系统/内核/...根据比 \xe2\x80\x9creturn 地址\xe2\x80\x9d 更多的信息来排序事件调度。

\n\n

自然反应性问题应该有自然反应性解决方案，就像自然面向批处理的问题应该有自然批处理导​​向的解决方案一样。

\n\n

(*)= 几乎所有反应式框架都是基于传统同步内核构建的，例如 Linux；反应式内核正在不断发展，大型多处理器的到来将有助于使这些概念成为主流。

\n