ala*_*eno 7 concurrency scala actor akka typesafe
我正在编写一个应用程序来读取相对较大的文本文件,验证并转换数据(文本文件中的每一行都是一个自己的项目,大约有100M项目/文件)并创建某种输出.已经存在一个多线程Java应用程序(BlockingQueue在读取/处理/持久化任务之间使用),但我想实现一个同样的事情的Scala应用程序.
Akka似乎是构建并发应用程序的一个非常受欢迎的选择.不幸的是,由于演员的异步性,我仍然不明白单个演员能做什么或不能做什么,例如,如果我可以将演员作为传统工作者进行某种计算.
几篇文章说演员应该永远不会阻止,我理解为什么.但是阻止代码的给定示例总是只提到诸如阻塞文件/网络IO之类的东西......使得演员等待很短时间的事情当然是件坏事.
但是,如果演员是"阻挡",因为它实际上做了一些有用而不是等待的东西呢？在我的情况下,单行/文本项的处理和转换需要80ms,这是相当长的时间(纯处理,不涉及IO).这项工作可以直接由演员完成,还是应该使用Future(但是,如果我必须使用Futures,为什么首先使用Akka ......)？
Akka文档和示例表明,工作可以由演员直接完成.但似乎作者只做了非常简单的工作(比如在字符串上调用过滤器或递增计数器,就是这样).我不知道他们是否这样做是为了保持文档的简洁和简洁,或者因为你真的不应该在演员中做更多的事情.
你会如何为我的用例设计一个基于Akka的应用程序(读取文本文件,处理每一行需要相当长的时间,最终保持结果)？或者这是一种不适合Akka的问题？
这一切都取决于演员的类型.
我使用这个经验法则:如果你不需要和这个演员交谈,这个演员没有任何其他责任,那么可以阻止它做实际的工作.你可以将它视为一个Future,这就是我所谓的"工人".
如果阻塞不是叶节点(工作者)的actor,即工作分配器,则整个系统将减速.
有一些模式涉及工作拉/推或演员每个请求模型.这些中的任何一个都适合您的应用程序.你可以让一个经理为每件作品创建一个演员,当作品完成时,演员将结果发送回经理并去世.你也可以让一个演员活着,并要求该演员提供更多的工作.你也可以结合演员和期货.
如果您的处理更复杂并涉及多个阶段,有时您希望能够与工作人员交谈.在这种情况下,工作人员可以将工作委托给另一个演员或未来.
总结不要阻止经理/工作分配行为者.如果不降低系统速度,可以阻止工作人员.
免责声明:通过阻止我的意思是做实际的工作,而不仅仅是忙碌的等待,这是永远不会好的.