根据"Effective Akka",平衡调度员很快就会被弃用.我将开始研究一些(单机)生产者/消费者代码,该代码处理处理截然不同形状的工作量.我该怎么用?
我希望生产者阻止(akka块或线程块,我不关心)(类似于这个问题),因为它将从数据库游标中管道204,000个条目:D
为我自己的模式编写锅炉板似乎过于沉重.管道中必须有新的东西取代平衡调度员.
紊乱的自我/思路的笔记.
我想要解决的问题:
使用尽可能少的代码编写具有2个actor类的生产者 - 消费者系统,这些类可以使单个机器的处理能力饱和.另外,不要一次性从消费者那里发送所有工作作为a)有很多工作(我不知道子邮箱的大小限制是多少)和b)工作有不同的形状.
方法/假设
我没有看到一个平衡调度员的例子,所以我对它的作用或如何使用它的期望很可能会被扭曲.调度程序似乎是一个与整个actor系统相关联的概念,并且文档表明要求基于平衡调度程序的actor系统的所有actor应该能够处理相同的消息(或者换句话说,可能是相同的actor类型) .
如果情况确实如此,那么假设并没有真正地映射到prod-cons,因为cons驱动程序必须在actor系统之外.作为另一个系统中的演员或app启动中的基于future的ask循环.平衡调度程序中的actor类型总是可以将逻辑和消息类型变成prod,但这将是一个相当讨厌的hack.或者也许actor系统启动有一个钩子,可以用来管道消息队列满(但这似乎不是一个很好的做事方式).我得出结论,平衡的调度员确实很讨厌.
上面的假设是错误的,路由器文档的结尾有这样的说法:
乍一看,BalancingDispatcher和路由器之间似乎有重叠,但它们相互补充.平衡调度员负责管理演员,而路由器负责决定哪个消息去哪里.路由器也可以拥有跨越多个actor系统的子系统,甚至是远程系统,但是调度程序位于单个actor系统中.
对于我的问题,哪种情况固化:D
好的,所以使用平衡调度程序+循环路由器指定的子actor可能会做到这一点.但附加共享邮箱的大小在哪里(从下面的一般概述,可选参数mailboxcapacity
,mailbox-type
似乎这样做).
链接
这里有三个概念.调度程序,路由器和邮箱.
总体概述
上面链接的最新文档似乎没有提到平衡调度程序被弃用.