concurrency - 基础知识 |线程与响应式(Reactive)并发模型

Question

我是响应式编程世界的完全新手。我正在研究 Akka Actors 作为开始使用的步骤。

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

对于来自客户端的每个请求，都会产生一个新线程。

这意味着所有底层代码的执行都附加到该线程并连续发生。显然，即使代码的一部分存在瓶颈(远程 Web 服务调用等)，线程也会被阻塞并等待并保持空闲。

服务器(容器)有一个固定的线程池来容纳最大并发线程数，显然，由于瓶颈，它们会很快运行线程。

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

所有逻辑不再附加到单个线程并串行执行。

执行流程是响应式(Reactive)的(即在消息上，一个actor 被触发)。

现在我的问题:

假设两个模型中都存在远程 webservice 调用的瓶颈。
Actor 模型如何帮助提高 CPU/核心利用率？我们不会有同样的问题，actor 中的执行线程被阻塞吗？
例如:如果此网络服务调用同时阻止了 200 个参与者？不是说当前有 200 个线程被阻塞了吗？
我知道仍然会有其他参与者对其他上游事件使用react。这就是我们所说的更好地利用 CPU 吗？

在线程模型中，仅仅是线程池的小尺寸是问题的原因吗？

Actor 子系统没有线程池来生成新的 Actor 并对特定事件使用react吗？如果是，那我们不是有同样的问题吗？

如果这个问题完全愚蠢，请原谅我。

Answer 1

“假设瓶颈......”——在 Reactive 模型中你永远不会使用这样的服务，而是你会异步调用 web 服务的请求，并为最终的响应/错误配置一个处理程序。
如果您调用同步服务，您只是重新引入了所有批处理模式问题，从而使您的问题更加复杂。如果你不能直接使用，你会创建一个类似代理的服务作为一个苍白的模仿 (*)。

当响应到达时，处理程序可以解开继续操作所需的任何上下文。如果所述上下文相当于“堆栈 + 寄存器”，那么您的框架不是很好，但比拥有数百个内核线程上下文来解析消息要好得多。

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

总结:应用程序空间中的一个小数据结构，它包含继续操作所需的信息，比内核线程 + 用户线程 + 堆栈要好得多。不仅仅是因为它使用更少的资源；但是因为它更好地表达了您的解决方案，并允许底层框架/操作系统/内核/...根据比“返回地址”更多的信息对事件调度进行排序。

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

(*)= 几乎所有的响应式(Reactive)框架都建立在传统的同步内核之上，比如 linux；响应式(Reactive)内核正在不断发展，大型多处理器的出现将有助于将这些概念纳入主流。