是否应该使用像Akka这样的基础设施来阻止阻塞呼叫（到关系数据库）？

Question

我已经阅读了很多关于服务器端事件驱动编程的内容，主要是与Akka和Play有关。我理解减少活动线程数的潜在好处。然而，我不能围绕一个特定的场景：

想象一下，我的一个演员必须使用阻塞jdbc来执行数据库操作。如果我们遵循每个actor一个线程的简单假设，那意味着对DB的后续调用将以非常同步的方式执行。虽然线程消耗不会上升，但似乎这种方法非常不切实际，因为在获得数据库响应之前，客户端必须等待越来越长的时间。

这是专用线程池。我们可以运行有限数量的专用于数据库访问的线程，而不是为每个actor运行一个线程。虽然这种方法避开了每个角色运行一个线程的基本命题，但它肯定是可能的。

然而，在一般事件序列中，我没有看到这种方法的真正好处，对于一个项目，90％的客户端请求需要访问数据库。实际上，控制器/应用程序逻辑将在单个线程上运行，但数据访问逻辑不会。最后，我问自己，这与为应用程序本身运行线程池有何不同，只是在自己的线程中为每个请求提供服务。

如果我错了，请证明我，但我的数学不然。你为什么要采取这种情况？

Answer 1

这是一个非常普遍的问题，但这里有一些食物供您参考：

• 如果您想了解一个人如何处理阻止非阻塞应用程序中的API，请查看此question。
• 你没有明确说出来，但我的印象是你主要考虑非阻塞方法的性能原因。这不是最重要的部分。在我看来，非阻塞方法的最重要原因是容错。 reactive manifesto将其称为弹性。如果您按照我链接的问题的方法，您可以在您的应用程序中实现此功能。通过异步操作，您可以对应用进行隔离。
• 您通常会说数据库操作正在阻止。你是对的 JDBC 是阻止的。但SQL并不是目前唯一可用的数据库类型。想想 NoSQL解决方案，像MongoDB那样提供非阻塞客户端。今天的应用程序通常在内部使用大量的Web服务，可以轻松地以非阻塞方式使用。所以大部分时间你的非阻塞应用程序不应该包含90％的阻塞调用。

TLDR ：效果并不重要。弹性是：）