首页 文章

Akka的好用例[关闭]

提问于
浏览 955 次
567

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

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

12 回答

  • 14

    免责声明:我是Akka的PO

    除了提供一个更简单的并发smorgasbord和正确(演员,代理,数据流并发)和STM形式的并发控制 .

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

    • 交易处理(在线游戏,金融,统计,投注,社交媒体,电信......)

    • 向上扩展,向外扩展,容错/ HA

    • 服务后端(任何行业,任何应用)

    • 服务REST,SOAP,cometd等

    • 充当消息中心/集成层

    • 向上扩展,向外扩展,容错/ HA

    • 管理单元并发/并行(任何应用)

    • 正确

    • 易于使用和理解

    • 只需将jar添加到现有的JVM项目中(使用Scala,Java,Groovy或JRuby)

    • 批处理(任何行业)

    • Camel集成以与批处理数据源连接

    • Actors分割并征服批处理工作负载

    • 通讯枢纽(电信,网络媒体,移动媒体)

    • 向上扩展,向外扩展,容错/ HA

    • 游戏服务器(在线游戏,投注)

    • 向上扩展,向外扩展,容错/ HA

    • BI / datamining /通用计算

    • 向上扩展,向外扩展,容错/ HA

    • 在这里插入其他不错的用例

  • 17

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

    告诉你的老板你的AWS托管账单将减少10倍,这是一个明智的做法!嘘......不要告诉亚马逊...... :)

  • 23

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

    Akka提供的消息传递系统类似于Erlang的“让它崩溃”的心态 .

    所以这些例子需要不同级别的持久性和消息传递的可靠性:

    • 聊天服务器

    • MMO的网络层

    • 财务数据泵

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

    • REST服务器

    • 也许类似于WebMachine(猜测)

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

    不要被聊天服务器的例子弄得烦恼,把它想象成某类解决方案的例子 .

    凭借他们所有优秀的文档,我觉得这个问题,用例和示例存在差距 . 记住这些例子并非易事 .

    (仅用观看视频和玩源的经验编写,我没有使用akka实现任何功能 . )

  • 41

    到目前为止,我已经在两个真正的项目中使用它非常成功 . 两者都处于近实时交通信息领域(高速公路上的车辆中的交通),分布在多个节点上,在多方之间集成消息,可靠的后端系统 . 我不能自由地给客户提供具体信息,当我确实得到OK时可能会添加它作为参考 .

    Akka确实已经完成了这些项目,尽管我们从0.7版本开始 . (我们顺便使用scala)

    其中一个最大的优点是,您可以轻松地从演员和消息组成系统,几乎没有电子设备,它可以很好地扩展,没有手动线程的所有复杂性,并且几乎可以免费在对象之间传递异步消息 .

    它非常适合建模任何类型的异步消息处理 . 我宁愿用这种风格编写任何类型的(网络)服务系统,而不是任何其他风格 . (您是否曾尝试使用JAX-WS编写异步Web服务(服务器端)?这是很多管道工程) . 所以我会说任何不想挂在其中一个组件上的系统,因为所有内容都是使用同步方法隐式调用的,并且一个组件锁定某些东西 . 它非常稳定,故障的崩溃管理器解决方案确实运行良好 . 一切都很容易以编程方式设置,而不是单元测试 .

    然后是优秀的附加模块 . Camel模块确实可以很好地插入Akka,并通过可配置的 endpoints 实现异步服务的轻松开发 .

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

  • 215

    您可以将Akka用于几种不同的事情 .

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

    • 网站上的实时更新(例如观看次数,喜欢......)

    • 显示实时用户评论

    • 通知服务

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

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

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

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

    自Google Reader关闭以来,我开始使用RSS阅读器,当然使用Akka . 这完全是关于我的封装服务 . 作为结论:演员模型本身就是你应该首先采用的,而Akka是一个非常可靠的框架,可以帮助你实现它,并带来很多好处 .

  • 16

    我们在口语对话系统中使用Akka(primetalk) . 内部和外部 . 为了在单个集群节点上同时运行许多电话通道,显然需要有一些多线程框架 . Akka的工作非常完美 . 我们之前曾经遇到过java-concurrency的噩梦 . 和Akka一样,它就像一个秋千 - 它只是起作用 . 坚固可靠 . 24 * 7,不停 .

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

    要进行复杂信号处理的互连,我们使用SynapseGrid . 它具有复杂actor系统中DataFlow的编译时检查的好处 .

  • 36

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

  • 306

    我们如何使用它的一个例子是在借记卡/信用卡交易的优先级队列上 . 我们有数百万这些,工作的努力取决于输入字符串类型 . 如果交易是CHECK类型,我们只有很少的处理,但如果它是一个销售点,那么还有许多工作要做,例如合并元数据(类别,标签,标签等)并提供服务(电子邮件/短信提醒,欺诈检测,低资金余额等) . 基于输入类型,我们组成处理作业所需的各种特征(称为mixins)的类,然后执行工作 . 所有这些工作都以不同金融机构的实时模式进入同一队列 . 一旦数据被清理,它就被发送到不同的数据存储以进行持久性,分析或推送到套接字连接,或者发送到Lift comet actor . 工作人员不断自我 balancer 工作,以便我们能够尽快处理数据 . 我们还可以为关键决策点捕捉其他服务,持久性模型和stm .

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

    Akka允许您像传统的esb一样传递消息,但速度快!它还为您提供框架中的工具,以管理解决方案所需的大量actor池,远程节点和容错 .

  • 18

    我们正在大规模的Telco项目中使用Akka(遗憾的是我无法透露很多细节) . 通过Web应用程序远程部署和访问Akka actor . 通过这种方式,我们有一个基于Google protobuffer的简化RPC模型,我们使用Akka Futures实现并行化 . 到目前为止,这个模型运作得非常出色 . 一个注意事项:我们正在使用Java API .

  • 23

    我正在尝试Akka(Java api) . 我试过的是比较Akka的演员并发模型与普通Java并发模型(java.util.concurrent类)的并发模型 .

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

    对于Akka,我使用了BalancedDispatcher(用于线程之间的负载 balancer )和RoundRobinRouter(以限制我的函数actor) . 对于Java,我使用了简单的fork join技术(没有任何工作窃取算法实现),它会分叉映射/减少执行并加入结果 . 中间结果保存在阻塞队列中,以使连接尽可能并行 . 也许,如果我没有错,那将模仿Akka演员的“邮箱”概念,在那里他们收到消息 .

    观察:直到中等载荷(约50000弦输入),结果具有可比性,在不同的迭代中略有不同 . 但是,当我将负载增加到~100000时,它会挂起Java解决方案 . 在这种情况下,我使用20-30个线程配置了Java解决方案,并且在所有迭代中都失败了 .

    将负荷增加到1000000对Akka来说也是致命的 . 我可以与任何有兴趣进行交叉检查的人分享代码 .

    所以对我来说,似乎Akka比传统的Java多线程解决方案更好 . 可能原因是斯卡拉引擎盖下的魔力 .

    如果我可以将问题域建模为事件驱动的消息传递,我认为Akka是JVM的一个很好的选择 .

    测试执行于:Java版本:1.6 IDE:Eclipse 3.7 Windows Vista 32位 . 3GB内存 . 英特尔酷睿i5处理器,2.5 GHz时钟速度

    请注意,用于测试的问题域可以辩论,我试图尽可能公平,因为我的Java知识允许:-)

  • 76

    我最近implemented在Akka中的规范 Map 缩减示例:字数 . 所以它是Akka的一个用例:更好的性能 . 它更多的是JRuby and Akka's actors的实验,但它也表明Akka不仅仅是Scala或Java:它适用于JVM之上的所有语言 .

  • 37

    我们在几个工作项目中使用Akka,其中最有趣的是与车辆碰撞修复有关 . 主要在英国,但现在扩展到美国,亚洲,澳大拉西亚和欧洲 . 我们使用演员来确保实时提供碰撞修复信息,以实现安全且经济有效的车辆维修 .

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

相关问题