ChatGPT解决这个技术问题 Extra ChatGPT

Akka 框架的最佳用例是什么 [关闭]

关闭。这个问题是基于意见的。它目前不接受答案。想改进这个问题?更新问题,以便可以通过编辑这篇文章用事实和引用来回答它。 8年前关闭。改进这个问题

我听说过很多关于 Akka 框架(Java/Scala 服务平台)的评论,但到目前为止还没有看到很多实际的用例示例。所以我很想听听开发人员成功使用它的事情。

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

从问题开始并找到解决方案不是比找到解决方案并寻找问题来应用它更容易吗?我的猜测是,使用 RMI,Akka 和它的 actor 看起来更容易/更简单地编写代码。
是的,如果我有特定的问题要解决。无论如何,我并不是在寻找“使用 Akka 的借口”,但我有兴趣了解更多信息。这也可能有助于解决未来的问题,但主要是为了持续的学习过程。
存在相关问题,但有关将 AKKA 应用于现有应用程序 + 一些用例:stackoverflow.com/questions/16595685/…
Akka 是比 JMS 或 MQ 风格的分布式消息队列系统更好的解决方案。对于最近问完全相同的问题的我自己来说,这是理解它的最佳方式:“我了解如何使用它,看看我可以在哪里使用它,但我看不出这会在哪里提供真正的优势”。 Akka 背后的核心设计假设比 JMS/MQ 背后的要好得多,特别是在进程隔离、无锁设计和重试/故障处理方面。其次,API 比 JMS/MQ 工具优雅得多。
@user2684301 嗯。我发现这个答案有点不公平,以苹果到橘子的方式。 MQ 是(逻辑上)简单的构建块,其功能远不如 Akka,我不会将它们并排比较。但我想如果我将它理解为“与使用 JMS 构建的分布式系统相比,以声明方式编写”,那么它会更有意义。

R
Raymond Roestenburg

到目前为止,我已经在两个实际项目中非常成功地使用了它。两者都在近乎实时的交通信息领域(交通如高速公路上的汽车),分布在多个节点上,集成多方之间的消息,可靠的后端系统。我还不能自由地提供客户的具体细节,当我得到确定时,也许可以将其添加为参考。

Akka 确实在这些项目上取得了成功,即使我们从 0.7 版开始。 (顺便说一下,我们正在使用 scala)

最大的优势之一是您可以轻松地用几乎没有样板的演员和消息组成一个系统,它的扩展性非常好,没有手动线程的所有复杂性,并且您几乎可以免费获得对象之间的异步消息传递。

它非常适合对任何类型的异步消息处理进行建模。我更愿意以这种风格编写任何类型的(Web)服务系统,而不是任何其他风格。 (您是否曾经尝试过使用 JAX-WS 编写异步 Web 服务(服务器端)?这需要大量的工作)。因此,我会说任何不想挂在其组件之一上的系统,因为所有内容都是使用同步方法隐式调用的,并且一个组件正在锁定某些东西。它非常稳定,让它崩溃 + 主管的失败解决方案真的很有效。一切都很容易以编程方式设置,并且不难进行单元测试。

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

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


在您看来,与使用消息传递后端(例如 ActiveMQ)进行消息传递相比,这种方法有什么好处?
MQ 产品确实适用于不同的用例。不同的保证和非常不同的性能。 MQ 产品需要大量设置,您不会像使用对象那样在此类产品中使用队列。 Actor 是 akka 中的一等公民,您可以随意使用它们,类似于使用对象的方式,因此在您的编程模型中和在设置中的开销要少得多。您将更多地使用 MQ 产品来与其他外部系统集成,而不是构建系统的“内部”,而这是您将使用 actor 的目的。
DBP 案例研究的新 URL 是 downloads.typesafe.com/website/casestudies/…
建立@RaymondRoestenburg re:MQ 系统和替代方案。例如,RabbitMQ 是基于一种基于角色的编程语言 Erlang 构建的。这是考虑参与者和 MQ 之间的关系(和区别)的一种方式。同时 Apache Spark 既不是 worker-and-queue 也不是基于 Actor,但可以与 Akka 一起使用:Typesafe demonstrates how to use Spark Streaming with Akka
@RaymondRoestenburg 您忽略了 Actor 模型按原样促进了类似意大利面条的结构。你写的《Akka in Action》一书就是对这个“特性”的最好示范。代码示例处理相当基本的故事。然而,工作流程很难从代码中理解和遵循。一个相关的问题是,Akka 代码将以您可以想象的最具侵入性的方式在您的业务逻辑中不可逆转。比任何其他非参与者框架都要多。如果不将其分解为不同的单独部分,就不可能编写基本的工作流程。
V
Viktor Klang

免责声明:我是 Akka 的 PO

除了提供一个更容易推理和正确的并发大杂烩(参与者、代理、数据流并发)以及 STM 形式的并发控制。

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

交易处理(在线游戏、金融、统计、博彩、社交媒体、电信……)扩展、扩展、容错/HA 服务后端(任何行业、任何应用程序)服务 REST、SOAP、cometd 等充当消息中心/集成层纵向扩展、横向扩展、容错/HA 管理单元并发/并行(任何应用程序) 正确 易于使用和理解 只需将 jars 添加到您现有的 JVM 项目(使用 Scala、Java、Groovy 或JRuby) 批处理(任何行业) Camel 集成以连接批处理数据源参与者分而治之批处理工作负载通信中心(电信、网络媒体、移动媒体)扩展、扩展、容错/HA 游戏服务器(在线游戏、博彩)扩展、扩展、容错/HA BI/数据挖掘/通用计算 扩展、扩展、容错/HA 在此处插入其他不错的用例


我了解 Futures 和 STM 的好处,但没有为参与者找到好的用例。对于游戏或投注服务器,在负载均衡器后面使用 Actor 与多个应用服务器相比有什么优势?
@ViktorKlang POs!= 技术主管。他们一起工作,但角色不同。
s
surfmuggle

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

在 JVM 上传递的 Erlang OTP 样式消息为在现有库和应用程序服务器的肩膀上开发实时系统提供了一个很好的系统。

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


那么公平地说这是(一些)长延迟请求的情况,每个请求的单线程不能很好地扩展?
我认为actor编程的重要部分通常是消息流。一旦您开始在没有副作用的数据流中进行概念化,您只希望每个节点发生尽可能多的流。这与高性能计算有很大不同,因为您有半同质的作业,不发送消息并且需要很长时间来处理。我认为基于 actor 的 Fibonacci 实现是一个非常有限的示例,因为它没有展示为什么使用 actor,而只是说明 actor 会瘫痪 taks。考虑用例的事件驱动架构。
事件驱动架构是一种不同的思考问题的方式。如果您正在考虑使用 Akka 进行编码,那么值得一读来自 manning 的 Erlang OTP in Action。 akka 中的许多构造都受到 Erlang OTP 的影响,这本书为您提供了 Jonas Boner 以他的方式构建 akka api 的原理。阿卡是你所站立的一座大山!如果您的演员通过状态更改保持持久性,您真的需要每秒写入 10k 次吗?
韦德,你们如何处理消息保证?您提到:(电子邮件/短信警报、欺诈检测、资金余额不足等),我认为这些可能会发送给远程参与者?您如何确保这些操作实际发生?如果节点在处理欺诈警报时发生故障怎么办?它永远消失了吗?你有一个最终一致的系统来清理它吗?谢谢!
好问题詹姆斯。很明显,它适合不需要紧急回复的系统。例如,您可以处理信用卡账单;计算;发送电子邮件等。我真的很想知道在需要回复时如何处理这些事情(交易)。在最后;如果请求来自外部(互联网用户;呼叫中心的代表等);他或她等待答复。我如何确定子任务(异步执行)被执行;在 xa 交易中以便我可以回复回复?
p
piotrga

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

告诉你的老板,你的 AWS 托管费用将下降 10 倍,这很容易!嘘......虽然不要告诉亚马逊...... :)


而且我忘了提到 akka 期货的一元性质,它导致更清洁的并行代码为我们节省了数千次代码维护......
我假设呼叫是高延迟,低吞吐量?比如调用其他服务器,等待响应(代理)?
L
Luciano Fiandesio

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


你能告诉我们更多吗? Afaik Futures 不能通过网络发送(序列化)。你会使用很多期货和很少的演员,还是两者之间的混合,或者......?您使用 protobuf 进行所有序列化并作为消息发送给参与者?
这似乎可以在没有 Akka 的情况下轻松处理。
TDC 是 Fiaddesio 的电信公司。
t
tylerweir

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

Akka 提供了一个类似于 Erlang 的“让它崩溃”心态的消息系统。

因此,示例是需要不同级别的消息传递的持久性和可靠性的事物:

聊天服务器

MMO 的网络层

金融数据泵

iPhone/手机/任何应用程序的通知系统

REST 服务器

也许类似于 WebMachine 的东西(猜测)

Akka 的优点在于它为持久性、STM 实现、REST 服务器和容错提供了多种选择。

不要对聊天服务器的示例感到恼火,将其视为某类解决方案的示例。

凭借他们所有出色的文档,我觉得这个确切的问题、用例和示例之间存在差距。请记住,这些示例并非微不足道。

(写的只有看视频和玩源码的经验,我没有用akka实现过。)


谢谢——我并不是说聊天服务器一定不好,只是我想要补充的例子;更容易更好地了解潜力。
想知道 REST 服务器如何适合这里吗?您是在 Node.js 风格的异步服务器的上下文中提到它吗?感谢您分享示例用例。我发现它们很有用。
r
rossputin

我们在工作中的几个项目中使用 Akka,其中最有趣的是与车辆碰撞修复有关。主要在英国,但现在扩展到美国、亚洲、大洋洲和欧洲。我们使用参与者来确保实时提供碰撞修复信息,以实现安全且具有成本效益的车辆维修。

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


那么如果非要选的话,你最喜欢哪个方面呢?其他框架的现有集成、自动容错还是其他?
从个人的角度来看,我最喜欢 Akka 带来的提升的抽象级别。从企业的角度来看,它是集成能力。必须谋生,Akka 很好地涵盖了商业和娱乐:-)
您能否详细说明消息的流程?用户是否是维修店的人,将有关崩溃的详细信息输入到 http 表单中,然后将数据发送到服务器。这是否会创建由 akka 处理的消息?怎么处理这个消息?提取输入的信息以查询数据库,然后将回复排队发送回网络前端?
J
Joa Ebert

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

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

网站上的实时更新(例如浏览量、喜欢的...)

显示实时用户评论

通知服务

搜索和所有其他类型的服务

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

我还将 Akka 用于 PCB 自动布线器应用程序,其想法是能够从笔记本电脑扩展到数据中心。你给它的权力越大,结果就会越好。如果您尝试使用通常的并发性,这将非常难以实现,因为 Akka 还为您提供了位置透明性。

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

自从 Google Reader 关闭后,我开始使用 RSS 阅读器,当然是使用 Akka。对我来说,这都是关于封装服务的。结论:actor 模型本身是您应该首先采用的,Akka 是一个非常可靠的框架,可以帮助您实现它,并在此过程中获得很多好处。


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

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

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

对于 Akka,我使用了 BalancedDispatcher(用于线程之间的负载平衡)和 RoundRobinRouter(以限制我的函数 actor)。对于 Java,我使用了简单的 fork join 技术(在没有任何工作窃取算法的情况下实现),它将 fork map/reduce 执行并连接结果。中间结果保存在阻塞队列中,以使连接尽可能并行。如果我没记错的话,这可能会以某种方式模仿 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 知识允许 :-)


“我可以与任何有兴趣进行交叉检查的人分享代码。”如果你不介意,我愿意。
我也想要代码,你能发布一个github链接吗?
感谢您的关注。不幸的是,我在设置 github 存储库时遇到了一些问题。如果你能给我你的电子邮件,我可以通过源代码邮寄。并为迟到的回复感到遗憾!
@sutanudalui 请问您还有代码吗,如果有,我可以分享我的电子邮件吗?
M
Matthias L. Jugel

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


您是否也在使用 Akka 的容错功能?
如果我们可以访问 Spark 集群,那么 Spark Streaming 怎么样?
A
Arseniy Zhizhelev

我们在口语对话系统 (primetalk) 中使用 Akka。无论是对内还是对外。为了在单个集群节点上同时运行大量电话通道,显然需要一些多线程框架。 Akka 工作得非常完美。我们以前对 java-concurrency 有过噩梦。使用 Akka,它就像一个秋千——它很简单。坚固可靠。 24*7,不间断。

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

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


D
Daniel Ribeiro

我最近implemented在 Akka 中使用了规范的 map-reduce 示例:字数。所以这是 Akka 的一个用例:更好的性能。这更像是对 JRuby and Akka's actors 的一次实验,但它也表明 Akka 不仅仅是 Scala 或 Java:它适用于 JVM 之上的所有语言。


您知道什么是更好的性能(以及与哪个替代方案相比)吗?这是由于在 JVM 上使用 JRuby(与本机 Ruby 相比),由于非阻塞 I/O 或其他原因导致的可扩展性?
我写的比较是:Jruby 顺序 VS Jruby 与演员。因此,唯一可以负责更快执行的就是参与者的参与。实验中没有 I/O 参与(从磁盘加载文件,但在设置基准计时器之前完成)。
我最近也实现了一个 map reduce 示例,但它只是普通的 vanilla java github.com/chaostheory/jibenakka