scala – Akka(1节点产品/缺点)：BalancingDispatcher即将被弃用

我希望生产者阻止(akka块或线程块,我不在乎)(similar to this question),因为它将从数据库游标中输入204,000个条目：D

为我自己的模式编写boiler plate似乎太过沉重.管道中必须有新的东西取代平衡调度员.

紊乱的自我/思路的笔记.

我想要解决的问题：

使用尽可能少的代码编写具有2个actor类的生产者 – 消费者系统,这些类可以使单个机器的处理能力饱和.另外,不要一次性从消费者那里发送所有工作作为a)有很多工作(我不知道子邮箱的大小限制是多少)和b)工作有不同的形状.

方法/假设

?我没有看到一个平衡调度员的例子,所以我对它的作用或如何使用它的期望很可能会被扭曲.调度程序似乎是一个与整个actor系统相关联的概念,并且文档表明要求基于平衡调度程序的actor系统的所有actor应该能够处理相同的消息(或者换句话说,可能是相同的actor类型) .

如果情况确实如此,那么假设并没有真正地映射到prod-cons,因为cons驱动程序必须在actor系统之外.作为另一个系统中的演员或app启动中基于future的ask循环.平衡调度程序中的actor类型总是可以将逻辑和消息类型变为prod,但这将是一个相当讨厌的hack.或者,actor系统启动可能有一个钩子,可以用来管道消息队列满(但这似乎不是一个很好的做事方式).我得出结论,平衡的调度员确实很讨厌.

上面的假设是错误的,路由器文档的结尾有这样的说法：

At first glance there seems to be an overlap between the
BalancingDispatcher and Routers,but they complement each other. The
balancing dispatcher is in charge of running the actors while the
routers are in charge of deciding which message goes where. A router
can also have children that span multiple actor systems,even remote
ones,but a dispatcher lives inside a single actor system.

对于我的问题,哪种情况固化：D

好的,所以使用平衡调度程序指定的子运算符循循环由器可能会成功.但是附加的共享邮箱的大小在哪里(从下面的概述,可选参数mailboxcapacity和mailbox-type似乎这样做).

链接

这里有三个概念. The dispatcher,The router和mailbox.

General overview

上面链接的最新文档似乎没有提到平衡调度程序被弃用.