Java 参与序列过程的Akka演员饥饿

Bisuness逻辑

我们需要完成以下业务逻辑：

100万次做：

下载索引i中的文件

解压缩文件

从文件中提取一些信息

删除该文件

当前Akka解决方案

我们目前拥有的Akka解决方案创建了100万个参与者，他们负责下载一个文件，完成后，他们创建了一个参与者来完成步骤2、3、4

问题

一旦我们运行了这个过程，我们就遇到了这样一种情况：Akka将下载演员放在最优先的位置，而其余的演员则处于饥饿模式

我们知道，随着机器磁盘越来越满，因为下载参与者不断下载，但其他参与者没有机会扫描和删除文件

问题

有没有办法迫使阿克卡不要让演员们挨饿

有没有办法告诉下载参与者等待，直到收到可以继续下载的通知（例如，磁盘中的并行文件不超过1000个）

---

谢谢。

对两种类型的参与者使用不同的调度器：

在配置中，可以将单独的调度程序定义为（例如）：

然后您可以在创建时将其分配给特定的参与者：

val myActor = context.actorOf(Props[MyActor].withDispatcher("my-dispatcher"), "myactor1")

调度程序实际上是线程池。将这两个操作分开可以保证缓慢的阻塞操作不会使另一个操作挨饿。这种方法通常被称为批量标题，因为其思想是，如果应用程序的一部分出现故障，其余部分将保持响应

---

有关更多信息，请参见问题2：仅使用1000个参与者，负责所有步骤->磁盘上最多1000个文件，不可能饥饿，因为一个参与者负责整个步骤链。您可以使用一个包含所有要下载的文件的队列，这样1000名参与者在处理完他们的文件后就可以请求一个新文件。1000000名参与者同时下载1000000个文件是胡说八道。单线程可以更快地完成这项工作。步骤2-4应组合在单个作业中，并提交到大小为availableProcessors+1的线程池。

val myActor = context.actorOf(Props[MyActor].withDispatcher("my-dispatcher"), "myactor1")