Ray*_*urg 319
到目前为止,我已经在两个真正的项目中使用它非常成功.两者都处于近实时交通信息领域(高速公路上的车辆中的交通),分布在多个节点上,在多方之间集成消息,可靠的后端系统.我还不能自由地给客户提供具体信息,当我确实得到确定时可能会添加它作为参考.
尽管我们从0.7版本开始,Akka已经真正完成了这些项目.(我们顺便使用scala)
其中一个巨大的优势是,您可以轻松地从演员和消息中构建一个系统,而且几乎没有电子设备,它可以很好地扩展,而不需要手动线程的所有复杂性,并且几乎可以免费在对象之间传递异步消息.
它非常适合建模任何类型的异步消息处理.我宁愿用这种风格编写任何类型的(网络)服务系统,而不是任何其他风格.(您是否曾尝试使用JAX-WS编写异步Web服务(服务器端)？这是很多管道工程).所以我会说任何不希望挂在其中一个组件上的系统,因为所有内容都是使用同步方法隐式调用的,并且一个组件锁定某些东西.它非常稳定,故障的崩溃+主管解决方案确实运行良好.一切都很容易以编程方式设置,并且不难进行单元测试.
然后是优秀的附加模块.Camel模块确实可以很好地插入Akka,并通过可配置的端点实现异步服务的轻松开发.
我对框架非常满意,它正在成为我们构建的连接系统的事实标准.
Vik*_*ang 219
免责声明:我是Akka的PO
除了提供一个更简单的并发smorgasbord和正确(演员,代理,数据流并发)和STM形式的并发控制.
以下是您可能会考虑的一些用例:
Wad*_*old 79
我们如何使用它的一个例子是在借记卡/信用卡交易的优先级队列上.我们有数百万这些,工作的努力取决于输入字符串类型.如果交易是CHECK类型,我们只有很少的处理,但如果它是一个销售点,那么有许多事情要做,例如合并元数据(类别,标签,标签等)并提供服务(电子邮件/短信提醒,欺诈检测,低资金余额等).基于输入类型,我们组成处理作业所需的各种特征(称为mixins)的类,然后执行工作.所有这些工作都以不同金融机构的实时模式进入同一队列.一旦数据被清理,它就被发送到不同的数据存储以进行持久性,分析或推送到套接字连接,或者发送到Lift comet actor.工作人员不断自我平衡工作,以便我们能够尽快处理数据.我们还可以为关键决策点捕捉其他服务,持久性模型和stm.
传递在JVM上的Erlang OTP样式消息为在现有库和应用程序服务器的肩膀上开发实时系统提供了一个很好的系统.
Akka允许您像传统的esb一样传递消息,但速度快!它还为您提供框架中的工具,以管理解决方案所需的大量actor池,远程节点和容错.
pio*_*rga 44
我们使用Akka异步处理REST调用 - 与异步Web服务器(基于Netty)一起,与每个用户请求模型的传统线程相比,我们可以将每个节点/服务器服务的用户数量提高10倍.
告诉你的老板,你的AWS托管账单将减少10倍,这是一个明智的做法!嘘......不要告诉亚马逊...... :)
Luc*_*sio 38
我们正在大规模的Telco项目中使用Akka(遗憾的是我无法透露很多细节).Akka actor由Web应用程序远程部署和访问.通过这种方式,我们有一个基于Google protobuffer的简化RPC模型,我们使用Akka Futures实现了并行性.到目前为止,这个模型运作得非常出色.一个注意事项:我们正在使用Java API.
tyl*_*eir 37
如果您将聊天服务器抽象到一个级别,那么您将得到答案.
Akka提供的消息系统类似于Erlang的"让它崩溃"的心态.
所以示例是需要不同级别的持久性和消息传递可靠性的事物:
关于Akka的好处是它为持久性提供的选择,它是STM实现,REST服务器和容错.
不要被聊天服务器的例子弄得烦恼,把它想象成某类解决方案的例子.
凭借他们所有出色的文档,我觉得这个问题,用例和示例存在差距.记住这些例子并非易事.
(仅根据观看视频和玩源的经验编写,我没有使用akka实现任何功能.)
ros*_*tin 24
我们在几个工作项目中使用Akka,其中最有趣的是与车辆碰撞修复有关.主要在英国,但现在扩展到美国,亚洲,澳大拉西亚和欧洲.我们使用演员来确保实时提供碰撞修复信息,以实现安全且经济有效的车辆维修.
与Akka的问题更多的是"你不能用Akka做什么".它与强大的框架集成,强大的抽象和所有容错方面的能力使其成为一个非常全面的工具包.
Joa*_*ert 24
您可以将Akka用于几种不同的事情.
我正在一个网站上工作,我将技术堆栈迁移到Scala和Akka.我们将它用于网站上发生的所有事情.即使您可能认为聊天示例不好,但所有内容基本相同:
特别是实时更新很容易,因为它们归结为聊天示例.服务部分是另一个有趣的主题,因为您可以简单地选择使用远程actor,即使您的应用程序没有群集,您也可以轻松地将其部署到不同的计算机上.
我还将Akka用于PCB自动布线应用,其理念是能够从笔记本电脑扩展到数据中心.你给它的力量越大,结果就越好.如果您尝试使用通常的并发性,这非常难以实现,因为Akka还为您提供了位置透明性.
目前作为一个空闲时间项目,我正在构建一个仅使用actor的Web框架.同样,好处是从单个机器到整个机器集群的可扩展性.此外,使用消息驱动方法使您的软件服务从一开始就面向.你拥有所有那些漂亮的组件,彼此交谈但不一定彼此了解,生活在同一台机器上,甚至不在同一个数据中心.
自从Google Reader关闭后,我开始使用RSS阅读器,当然使用Akka.这完全是关于我的封装服务.作为结论:演员模型本身就是你应该首先采用的,而Akka是一个非常可靠的框架,帮助你实现它,并带来很多好处.
小智 18
我们正在使用akka及其camel插件来分发twimpact.com的分析和趋势处理.我们必须每秒处理50到1000条消息.除了使用camel进行多节点处理之外,它还用于将单个处理器上的工作分配给多个工作人员以获得最佳性能.效果很好,但需要了解如何处理拥堵.
sut*_*lui 18
我正在尝试Akka(Java api).我试过的是将Akka基于actor的并发模型与普通Java并发模型(java.util.concurrent类)进行比较.
用例是一个简单的规范映射,减少了字符数的实现.数据集是随机生成的字符串的集合(长度为400个字符),并计算其中元音的数量.
对于Akka,我使用了BalancedDispatcher(用于线程之间的负载平衡)和RoundRobinRouter(以限制我的函数actor).对于Java,我使用了简单的fork join技术(没有任何工作窃取算法实现),它会分叉映射/减少执行并加入结果.中间结果保存在阻塞队列中,以使连接尽可能并行.也许,如果我没有错,那将模仿Akka演员的"邮箱"概念,他们在那里接收消息.
观察:直到中等载荷(约50000弦输入),结果具有可比性,在不同的迭代中略有不同.但是,当我将负载增加到~100000时,它会挂起Java解决方案.在这种情况下,我使用20-30个线程配置了Java解决方案,并且在所有迭代中都失败了.
将负荷增加到1000000对Akka来说也是致命的.我可以与任何有兴趣进行交叉检查的人分享代码.
所以对我来说,似乎Akka比传统的Java多线程解决方案更好.也许原因在于Scala的引擎盖下魔力.
如果我可以将问题域建模为事件驱动的消息传递,我认为Akka是JVM的一个很好的选择.
测试执行于:Java版本:1.6 IDE:Eclipse 3.7 Windows Vista 32位.3GB内存.英特尔酷睿i5处理器,2.5 GHz时钟速度
请注意,用于测试的问题域可以辩论,我试图尽可能公平,因为我的Java知识允许:-)
Ars*_*lev 16
我们在口语对话系统(primetalk)中使用Akka .内部和外部.为了在单个集群节点上同时运行许多电话通道,显然需要有一些多线程框架.Akka的作品非常完美.我们之前曾经遇到过java-concurrency的噩梦.和Akka一样,它就像一个秋千 - 它只是起作用.坚固可靠.24*7,不停.
在频道内部,我们拥有并行处理的实时事件流.特别是: - 冗长的自动语音识别 - 由演员完成; - 混合少量音频源(包括合成语音)的音频输出制作者; - 文本到语音转换是在通道之间共享的一组独立的参与者; - 语义和知识处理.
为了实现复杂信号处理的互连,我们使用SynapseGrid.它具有复杂actor系统中DataFlow的编译时检查的好处.
Dan*_*iro 14
我最近在Akka中实现了规范的map-reduce示例:字数统计.所以它是Akka的一个用例:更好的性能.它更像是JRuby和Akka演员的实验而不是其他任何东西,但它也表明Akka不仅仅是Scala或Java:它适用于JVM之上的所有语言.