我知道这是一个非常不精确的问题,可能被认为不适合stackoverflow.不幸的是,较小的应用程序(就演员数量而言)和"类似教程"的应用程序无法帮助我发展关于消息调度开销的直觉以及"scala对象"和"CORBA对象"之间的粒度的快速点.
虽然几乎肯定保持与客户的对话状态,例如值得一个演员,但在大多数实际使用案例中,它将涉及由许多类建模的条件/并行/替代交互.这样就可以选择将actor视为非常复杂的服务的外观,类似于刚刚退役的EJB,或者类似于smalltalk对象,只要通信可能以异步方式实现,就可以在相互之间发送消息.
除了消息传递本身的开销之外,还会有生命周期管理所涉及的开销,并且我对由于根目录中的异常或其他错误导致整个子树的链接重新启动而导致的潜在问题持谨慎态度.
为了这个问题,我们可以假设绝大多数通信发生在一台机器上,并且网络交叉是微不足道的.
Ale*_*aga 15
我不确定你所说的"消息传递的开销"是什么意思.当不涉及网络/序列化时,开销可以忽略不计:一方将消息推入队列,另一方从其中读取消息.
Akka声称它可以在一台机器上以每秒5000万条消息的速度发送.这意味着您不会将actor用作复杂子系统的façade.你宁愿把它们塑造成更小的"工作单位".与方便时的smalltalk对象相比,它们可能更复杂.比方说,你可以KafkaConsumerActor使用内部其他"普通"类,如连接,配置等,这些不必是akka演员.但它仍然足够小,可以成为一个简单的工作单元做一件简单的事情(消费消息并将其发送到某处).
每秒5000万真的很多.
内存占用也非常小.Akka本身声称你只需要1GB的堆即可拥有约250万名演员.与典型系统所做的相比,确实没什么.
至于生命周期,创建一个actor并不比创建一个类实例和一个邮箱重得多,所以我并不认为它会那么重要.
这么说,通常你的系统中没有很多可以处理一条消息而死的actor.通常你会产生更长寿的演员.比如,根据您提供的参数计算抵押贷款还款的演员根本没有任何理由去死.
此外,Akka使用actor池(不同类型)非常简单.
所以这里的表现非常可调.
最后一点是你应该在上下文中比较Akka开销.例如,如果您的系统正在进行数据库查询,或者正在执行/执行HTTP请求,甚至执行某种重要的IO,那么这些活动的开销可能会使Akka的开销变得微不足道,因此您甚至不会考虑它.就像往返于50毫安的DB往返一样,相当于大约250万条akka消息的开销.有关系吗？
那么你能找到一个边缘案例场景,Akka会强迫你支付绩效惩罚吗？大概.阿卡不是金锤(也没有).
但考虑到上述所有因素,您应该考虑Akka是否是您特定环境中的性能瓶颈,或者您是否在微优化中浪费时间.