Akka的好用例[关闭]


605

我听说过很多关于Akka框架(Java / Scala服务平台)的赞誉,但是到目前为止,还没有看到很多对用例有用的实际用例。因此,我想听听有关开发人员成功使用它的知识。

仅一个限制:请不要包括编写聊天服务器的情况。(为什么?因为这已被过度用作许多类似事物的示例)


10
从问题开始并找到解决方案难道不是比有解决方案并寻找问题要解决的方法容易吗?我的猜测是,代替使用RMI,Akka及其参与者看起来更容易/更简单地为其编写代码。
Kennet 2010年

67
是的,如果我有特定的问题要解决。我绝不是在寻找“借用Akka”的方法,但是我有兴趣学习更多。这也可能有助于解决未来的问题,但主要是针对正在进行的学习过程。
StaxMan 2010年

有相关的问题,但有关申请AKKA为+一些使用情况下现有的应用程序:stackoverflow.com/questions/16595685/...
SES

2
与JMS或MQ样式的分布式消息队列系统相比,Akka是更好的解决方案。这是对最近问过一个完全相同的问题的我自己的最好方法:“我知道如何使用它,看看可以在哪里使用,但是看不到在哪里可以提供真正的优势”。Akka背后的核心设计假设要比JMS / MQ背后的假设要好得多,特别是在流程隔离,无锁设计和重试/故障处理方面。其次,该API比JMS / MQ工具要优雅得多。
user2684301 2014年

2
@ user2684301嗯。我发现这个回答有点不公平,以苹果为代表的方式。MQ是(从逻辑上)简单的构建基块,其作用比Akka少得多,我不会将它们并排比较。但是我想如果我把它读为“与使用声明式编写的使用JMS构建的分布式系统相比”,那么它会更有意义。
StaxMan 2014年

Answers:


321

到目前为止,我已经非常成功地在两个实际项目中使用了它。两者都位于接近实时的交通信息领域(交通流量就像高速公路上的汽车一样),分布在多个节点上,整合了多方之间的消息以及可靠的后端系统。我还没有随意提供有关客户端的详细信息,当我确定时,也许可以将其添加为参考。

Akka确实完成了这些项目,即使我们是从0.7版本开始的。(我们正在使用scala)

最大的优势之一是,您可以轻松地由参与者和消息组成几乎没有重复电镀的系统,它的伸缩性非常好,而无需手动卷入线程的所有复杂性,并且几乎可以免费在对象之间传递异步消息。

在对任何类型的异步消息处理进行建模方面非常好。与任何其他样式相比,我更喜欢以这种样式编写任何类型的(网络)服务系统。(您是否曾经尝试使用JAX-WS编写异步Web服务(服务器端)?这有很多问题)。因此,我想说任何不想挂在其组件之一上的系统,因为所有组件都使用同步方法隐式调用,并且该组件正在锁定某个对象。它非常稳定,让故障崩溃+主管解决故障的方法确实有效。一切都很容易通过编程进行设置,并且很难进行单元测试。

然后是出色的附加模块。Camel模块确实可以很好地插入Akka中,并可以轻松地开发具有可配置端点的异步服务。

我对该框架感到非常满意,它已成为我们构建的连接系统的事实上的标准。


14
与您认为使用消息传递后端(例如ActiveMQ)传递消息相比,此方法有什么好处?
magiconair

27
MQ产品确实适用于不同的用例。不同的保证和非常不同的性能。MQ产品需要大量的设置,因此您不会像使用对象那样使用此类产品中的队列。演员是akka的一等公民,您可以随意使用它们,类似于使用对象的方式,因此编程模型和设置中的开销都少得多。您将更多地使用MQ产品与其他外部系统集成,而不是构建系统的“内部”,而您将使用参与者。
雷蒙德·罗滕堡

26
新的URL为DBP案例研究是downloads.typesafe.com/website/casestudies/...
巴斯

2
在@RaymondRoestenburg的基础上重新构建:MQ系统和替代方案。RabbitMQ的,例如,是建立一个基于角色的编程语言,二郎。这是考虑参与者与MQ之间的关系(和区别)的一种方法。同时,Apache Spark既不是基于工作队列也不基于Actor的,BUT可以与Akka一起使用:Typesafe演示了如何在Akka中使用Spark Streaming
2015年

6
@RaymondRoestenburg您忽略了提及Actor模型按原样促进类似意大利面条的结构。您编写的“ Akka in Action”一书是此“功能”的最佳演示。代码示例处理相当基本的故事。但是,工作流很难理解和遵循代码。一个相关的问题是,Akka代码将以您所能想到的最具侵入性的方式在您的整个业务逻辑中不可逆转。比任何其他非参与者框架都要多。如果不将基本工作流程分解为不同的单独部分,那就根本不可能做到。
全神贯注

222

免责声明:我是Akka的PO

除了提供并发smorgasbord之外,它更易于推理和获取正确的内容(参与者,代理,数据流并发),并且采用STM形式的并发控制。

您可能会考虑以下一些用例:

  1. 交易处理(在线游戏,金融,统计,投注,社交媒体,电信等)
    • 扩大规模,扩大规模,容错/ HA
  2. 服务后端(任何行业,任何应用)
    • 服务REST,SOAP,cometd等
    • 充当消息中心/集成层
    • 扩大规模,扩大规模,容错/ HA
  3. 管理单元并发/并行(任何应用程序)
    • 正确
    • 易于使用和理解
    • 只需将罐子添加到您现有的JVM项目中(使用Scala,Java,Groovy或JRuby)
  4. 批处理(任何行业)
    • 骆驼集成以连接批处理数据源
    • 参与者分而治之
  5. 通讯中心(电信,网络媒体,移动媒体)
    • 扩大规模,扩大规模,容错/ HA
  6. 游戏服务器(在线游戏,投注)
    • 扩大规模,扩大规模,容错/ HA
  7. BI /数据挖掘/通用处理
    • 扩大规模,扩大规模,容错/ HA
  8. 在这里插入其他好的用例

10
我了解期货和STM的好处,但没有找到参与者的好用例。对于游戏或博彩服务器,在负载平衡器后面使用Actors与多个应用程序服务器相比有什么优势?
Martin Konicek 2013年

8
@ViktorKlang POs!=技术主管。他们一起工作,但角色不同。
taylorcressy

79

例如,在借记卡/信用卡交易的优先级队列中,我们将如何使用它。我们有数百万种这样的工具,而工作量取决于输入字符串的类型。如果交易的类型为CHECK,我们的处理量很少,但是如果是销售点,则有很多工作要做,例如与元数据合并(类别,标签,标签等)并提供服务(电子邮件/短信提醒,欺诈检测,资金余额不足等)。根据输入类型,我们组成处理工作然后执行工作所需的各种特征(称为混合)类。来自不同金融机构的所有这些工作都以实时模式进入同一队列。清除数据后,会将其发送到其他数据存储以进行持久性,分析,将其推送到套接字连接或提升到彗星演员。工作参与者不断地自我平衡工作负载,以便我们能够尽快处理数据。我们还可以加入其他服务,持久性模型和 对于关键的决策点。

在JVM上传递的Erlang OTP样式消息是在现有库和应用程序服务器的肩膀上开发实时系统的绝佳系统。

Akka允许您像传统方式一样进行消息传递 但是速度!它还为您提供了框架中的工具,以管理解决方案所需的大量参与者池,远程节点和容错能力。


1
因此,可以说是(某些)长延迟请求的情况,其中每个请求的单线程无法很好地扩展?
StaxMan 2010年

7
我认为总体上演员编程的重要部分是消息流。一旦开始概念化没有副作用的数据流,您只希望每个节点上发生尽可能多的流。这与高性能计算有很大的不同,因为您有半同质的工作,它们不发送消息,并且处理时间很长。我认为基于角色的斐波那契实现是一个非常局限性的示例,因为它没有显示出为什么使用角色,而仅表明了角色使工作瘫痪。将事件驱动的体系结构用于用例。
韦德·阿诺德

4
事件驱动的体系结构是思考问题的另一种方式。如果您正在考虑使用Akka进行编码,那么值得从配员中阅读Erlang OTP in Action。akka中的许多构造都受到Erlang OTP的影响,这本书为您提供了Jonas Boner为何以他的方式构建akka api的原理。阿卡(Akka)是您站立的一座大山!如果您的行为者通过状态变化而持久存在,那么您真的需要10k写第二个持久状态吗
Wade Arnold 2010年

8
韦德,你们如何处理消息保证?您提到:(电子邮件/短信警报,欺诈检测,资金余额低等),我认为这些可能会发送给远程参与者?您如何确保这些操作确实发生了?如果节点在处理欺诈警报时发生故障怎么办?它永远消失了吗?您是否有一个最终一致的系统来对其进行清理?谢谢!
詹姆斯

2
詹姆斯,好问题。显然,它适合不需要紧急回复的系统。例如,您可以处理信用卡账单;计算; 发送电子邮件等。我真的很想知道当需要回复时如何处理这些事情(事务)。在最后; 如果来自外部的请求(互联网用户;呼叫中心的代表等);他或她等待答复。如何确定子任务(异步执行)已执行?在XA交易中,以便我可以返回答复?
Kaan Yy 2012年

44

我们使用Akka异步处理REST调用-与异步Web服务器(基于Netty)一起使用,与每个用户请求模型的传统线程相比,我们可以将每个节点/服务器服务的用户数量提高10倍。

告诉老板,您的AWS托管账单将减少10倍,这很容易!嘘...虽然没有告诉亚马逊... :)


3
而且我忘了提及akka期货的一元性质,它导致更清晰的并行代码为我们节省了数千美元的代码维护工作
piotrga 2012年

8
我认为呼叫是高延迟,低吞吐量的吗?就像拨打其他服务器的电话一样,等待响应(代理)吗?
StaxMan 2012年

38

我们在大型电信项目中使用Akka(不幸的是,我无法透露很多细节)。Akka actor由Web应用程序远程部署和访问。这样,我们就有了一个基于Google protobuffer的简化的RPC模型,并使用Akka Futures实现了并行性。到目前为止,该模型运行良好。注意事项:我们正在使用Java API。


你能告诉我们更多吗?Afaik期货无法通过电汇发送(序列化)。您使用大量的期货和少量的参与者,还是两者之间的混合物?您将protobuf用于所有序列化并作为消息发送给参与者吗?
Aktau 2012年

好像没有Akka一样可以轻松处理。
Erik Kaplun 2014年

1
TDC是Fiaddesio案中的电信公司。
罗曼·卡根

37

如果您将聊天服务器抽象为一个级别,那么您将得到答案。

Akka提供的消息传递系统类似于Erlang的“让它崩溃”的思想。

因此,有些例子需要改变消息传递的持久性和可靠性:

  • 聊天服务器
  • MMO的网络层
  • 财务数据泵
  • iPhone /手机/任何应用程式的通知系统
  • REST服务器
  • 也许类似于WebMachine(猜测)

关于Akka的好处是它为持久性提供了选择,它是STM实现,REST服务器和容错能力。

不要被聊天服务器的例子所困扰,可以将其视为某种解决方案的例子。

有了他们所有出色的文档,我觉得这个确切的问题,用例和示例是一个空白。请记住,这些示例是不平凡的。

(仅凭观看视频和播放源的经验写的,我使用akka并没有实现任何东西。)


2
谢谢-我并不是说聊天服务器不一定很糟糕,只是我想补充例子。更容易获得潜在的想法。
StaxMan 2010年

想知道REST服务器如何适合这里?您是否在Node.js样式异步服务器的上下文中提到它?感谢您分享示例用例。我发现它们很有用。
software.wikipedia

24

我们在工作中的多个项目中使用了Akka,其中最有趣的是与车辆碰撞修复有关。主要在英国,但现在扩展到美国,亚洲,大洋洲和欧洲。我们使用参与者来确保实时提供碰撞修复信息,从而能够安全,经济地修复车辆。

Akka的问题实际上更多是“您不能使用Akka做些什么”。它具有与强大的框架集成,强大的抽象以及所有容错方面的能力,使其成为非常全面的工具包。


那么,如果必须选择,您最喜欢哪个方面?现有与其他框架的集成,自动容错或其他功能?
StaxMan 2010年

6
从个人角度来看,我最喜欢的是Akka带来的提升的抽象水平。从企业的角度来看,它是集成功能。

您能详细说明一下消息流吗?用户是修理厂的人,并且将有关崩溃的详细信息输入到http表格中,然后将数据发送到服务器。这是否会创建由akka处理的消息?用此消息做什么?提取输入的信息以查询数据库,然后将答复排队以将其发送回Web前端?
surfmuggle 18/09/26

24

您可以将Akka用于多种不同的事物。

我当时在一个网站上工作,在那里我将技术堆栈迁移到了Scala和Akka。我们几乎将它用于网站上发生的所有事情。即使您可能认为聊天示例很糟糕,但基本上都是相同的:

  • 网站上的实时更新(例如,观看次数,喜欢次数,...)
  • 显示实时用户评论
  • 通知服务
  • 搜索和所有其他类型的服务

尤其是实时更新很容易,因为它们可以归结为一个聊天示例专家。服务部分是另一个有趣的话题,因为您可以选择使用远程参与者,即使您的应用程序未集群,也可以轻松地将其部署到其他计算机上。

我还将Akka用于PCB自动路由器应用程序,其想法是能够从笔记本电脑扩展到数据中心。您提供的功率越多,结果将越好。如果您尝试使用通常的并发性,那么这将很难实现,因为Akka还为您提供了位置透明性。

目前,作为一个空闲时间项目,我正在仅使用参与者来构建Web框架。同样,好处是从单个计算机到整个计算机集群的可伸缩性。此外,使用消息驱动的方法可使您从一开始就面向软件服务。您拥有所有这些不错的组件,彼此交谈,但不一定彼此了解,它们位于同一台计算机上,甚至不在同一数据中心中。

自从Google Reader关闭以来,我首先使用了Akka,从RSS阅读器开始。对我而言,这一切都与封装服务有关。结论:角色模型本身是您首先应该采用的,而Akka是一个非常可靠的框架,可以帮助您实施该模型,并从中获得很多好处。


您好乔,您能解释一下如何使用消息来更新站点吗?内容作者是否有一个系统?他创建了新文章并点击保存。这是否创建一条消息,该消息将发送到处理传入流量的多个服务器。每个服务器都将尽快处理更新消息。然后,每个新的浏览器请求都会获得页面的更新版本?谢谢
surfmuggle

18

我们正在使用带有其骆驼插件的akkatwimpact.com分发我们的分析和趋势处理。我们必须每秒处理50到1000条消息。除了使用骆驼进行多节点处理外,它还用于将单个处理器上的工作分配给多个工作人员,以实现最佳性能。效果很好,但是需要对如何处理拥塞有所了解。


您还在使用Akka的容错功能吗?
Erik Kaplun 2014年

如果我们可以访问Spark集群,那么Spark Streaming怎么样?
skjagini

18

我正在尝试使用Akka(Java api)。我试图将Akka基于参与者的并发模型与普通Java并发模型(java.util.concurrent类)进行比较。

用例是一个简单的规范映射,减少了字符计数的实现。数据集是随机生成的字符串(长度为400个字符)的集合,并计算其中的元音数量。

对于Akka,我使用了BalancedDispatcher(用于线程之间的负载平衡)和RoundRobinRouter(以限制我的函数参与者)。对于Java,我使用了简单的fork联接技术(无需任何工作窃取算法即可实现),该技术将fork映射/减少执行并联接结果。中间结果保存在阻塞队列中,以使加入尽可能平行。如果我没有记错的话,那可能会模仿Akka演员的“邮箱”概念,他们会在此接收消息。

观察:直到中等负荷(〜50000弦输入),结果是可比较的,在不同的迭代中略有不同。但是,当我将负载增加到〜100000时,它将挂起Java解决方案。在这种情况下,我为Java解决方案配置了20-30个线程,但在所有迭代中均失败了。

将负载增加到1000000,对于Akka也是致命的。我可以与有兴趣进行交叉检查的任何人共享代码。

因此对我来说,Akka似乎比传统的Java多线程解决方案更好地扩展。可能的原因是Scala的内幕魔术。

如果我可以将问题域建模为传递事件的消息,那么我认为Akka是JVM的不错选择。

执行测试:Java版本:1.6 IDE:Eclipse 3.7 Windows Vista 32位。3GB内存。Intel Core i5处理器,时钟频率为2.5 GHz

请注意,用于测试的问题域可能会引起争议,并且我尝试尽可能公平地对待我的Java知识:-)


3
“我可以与有兴趣进行交叉检查的任何人共享代码。” 如果您不介意,我想。
n1r3 2012年

3
我也想要代码,您可以发布github链接吗?
Gautam

感谢您的关注。不幸的是,我在设置github存储库时遇到了一些问题。如果可以给我您的电子邮件,我可以通过源代码发送邮件。并为迟到的回复感到遗憾!
sutanu dalui

@sutanudalui请仍然提供代码,如果可以的话,我可以分享我的电子邮件吗?
周杰伦

16

我们在口语对话系统(Primetalk中使用Akka)中。内部和外部都可以。为了在单个群集节点上同时运行许多电话通道,显然必须具有一些多线程框架。Akka的作品非常完美。我们以前对Java-concurrency感到恶梦。与Akka一样,它就像秋千一样-确实有效。坚固可靠。24 * 7,不间断。

在通道内部,我们具有并行处理的实时事件流。特别是:-冗长的自动语音识别-由演员完成;-混合少数音频源(包括合成语音)的音频输出产生器;-文本到语音的转换是通道之间共享的一组独立角色;-语义和知识处理。

为了使复杂的信号处理相互连接,我们使用SynapseGrid。它具有在复杂参与者系统中对DataFlow进行编译时检查的优势。


14

我最近在Akka中实现了规范的map-reduce示例:字数统计。因此,这是Akka的一个用例:更好的性能。比起其他任何事情,它更像是JRuby和Akka参与者的实验,但它也表明Akka不仅是Scala或Java,它还可以在JVM之上的所有语言上运行。


您知道什么因素导致更好的性能(以及与哪种选择相比)吗?这是由于在JVM(相对于本机Ruby)上使用JRuby,还是由于非阻塞I / O或其他原因实现了可伸缩性?
StaxMan 2010年

2
我写的比较是:Jruby顺序VS Jruby与演员。因此,唯一负责快速执行的是参与者的参与。没有I / O参与实验(从磁盘加载文件,但是在设置基准计时器之前完成)。
丹尼尔·里贝罗

我最近还实现了map reduce的示例,但这只是普通的java github.com/chaostheory/jibenakka
chaostheory 2011年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.