scala - AKKA Actor 和数据库操作

Question

我试图弄清楚如何在使用 Actor 系统时最好地处理数据库操作。确实，数据库操作正在阻塞，而我们尽量不在 AKKA 中阻塞。

我在主文档中指出，一种处理方法是在路由器后面创建一个 Actor 池，可能在一个单独的 executionContext 上，这将处理数据库访问。

因此我有以下问题:

1 - databaseActors 是否一直保持连接打开？

2 - 它如何与许多数据库提供的连接池一起工作？

3 - 我们是否应该将两者结合起来，并让 DatabaseActor 每次被请求时都从池中请求一个新连接。如果不是，那么始终保持连接打开不是一件坏事吗？

4 - 有人可以向我解释使它成为避免线程饥饿的方法的微妙之处。例如使用 Play 或 Spray，请求的处理是一个异步任务，但是如果该任务需要数据库访问并且我们向 DatabaseActor 发送请求，数据库 Actor 上的 block (如果发生)是否不会诱导，异步任务中的一个 block ，导致可能的线程饥饿？

5 - 是否 100% 确定 DB ACID 属性确保了多次读写的安全性，因此发生在关系之前。

6 - 我正在使用也称为三重存储的语义数据库，并在我的请求期间大量使用语义推理能力。我还执行了很多写访问，有什么建议，关于调整池参数和参与者编号或专用执行上下文？

最好的，

米

Answer 1

1 - Does the databaseActors keep the connection open the all time?

Akka actor 是有状态的，也就是说，您可以安全地将状态(在本例中为数据库连接)存储在 actor 中。您可以编写自己的连接管理逻辑，也可以使用数据库驱动程序提供的逻辑。

2 - How does it work together with connection Pooling as offered by many database?

3 - Shall we combine both, and have the DatabaseActors request a new connection from the pool each time they are solicited. If not, isn't it keeping a connection open at all time a bad thing to do?

您可以将两者结合起来。池中的每个连接都有一个 Actor 。为什么你认为保持连接是一件坏事？拥有连接池的全部意义不在于重用资源(连接)，而不是每次都为创建/销毁它们付出代价。

4 - Can someone explain to me the subtle thing that make it an approach that avoid thread starvation. For instance using Play or spray, the handling of a request is an asynchronous task, however if that task need a database access and we send an ask to the DatabaseActor, does the block on the database Actor (if it occur) do not induce, a block in the asynchronous task, leading to possible thread starvation ?

如果您的数据库驱动程序正在阻塞，那么您最终也必须阻塞。推荐的做法是在单独的执行上下文/线程池中执行这段阻塞代码。或者，如果您可以选择具有完全异步且非阻塞的响应式数据库驱动程序(例如，用于 MongoDB 的 ReactiveMongo)的数据存储。

5 - Is it 100% sure the DB ACID property ensures the safety of the multiple read and write and therefore happens before relationship.

我不明白你这是什么意思。

6 - I'm using the semantic database also called triple store and make heavy using of semantic reasoning capability during my request. I also perform a lot of write access, any advise, concerning tuning parameters of pooling and actor numbers or dedicated execution context?

您绝对应该使用不同的执行上下文。参数的转换实际上取决于您的硬件配置和软件的其他细节(数据库类型、远程数据库与嵌入式数据库、请求/秒等)。
对于 Akka 调度程序，我认为没有一刀切的方法。它更像是一门艺术。我唯一的建议是确保您没有阻塞代码中的任何地方。