Java Akka 的好用例

Good use case for Akka

提问by StaxMan

I have heard lots of raving about Akkaframework (Java/Scala service platform), but so far have not seen many actual examples of use cases it would be good for. So I would be interested in hearing about things developers have used it succesfully.

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

Only one limitation: please do not include case of writing a chat server. (why? since this has been overused as an example for lots of similar things)

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

采纳答案by Raymond Roestenburg

I have used it so far in two real projects very successfully. both are in the near real-time traffic information field (traffic as in cars on highways), distributed over several nodes, integrating messages between several parties, reliable backend systems. I'm not at liberty to give specifics on clients yet, when I do get the OK maybe it can be added as a reference.

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

Akka has really pulled through on those projects, even though we started when it was on version 0.7. (we are using scala by the way)

尽管 Akka 是在 0.7 版本上开始的，但它确实完成了这些项目。（顺便说一下，我们正在使用 Scala）

One of the big advantages is the ease at which you can compose a system out of actors and messages with almost no boilerplating, it scales extremely well without all the complexities of hand-rolled threading and you get asynchronous message passing between objects almost for free.

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

It is very good in modeling any type of asynchronous message handling. I would prefer to write any type of (web) services system in this style than any other style. (Have you ever tried to write an asynchronous web service (server side) with JAX-WS? that's a lot of plumbing). So I would say any system that does not want to hang on one of its components because everything is implicitly called using synchronous methods, and that one component is locking on something. It is very stable and the let-it-crash + supervisor solution to failure really works well. Everything is easy to setup programmatically and not hard to unit test.

它非常适合建模任何类型的异步消息处理。与其他任何风格相比，我更愿意以这种风格编写任何类型的（网络）服务系统。（您是否曾经尝试过使用 JAX-WS 编写异步 Web 服务（服务器端）？这是很多管道）。所以我会说任何不想挂在其组件之一上的系统，因为所有东西都是使用同步方法隐式调用的，并且该组件正在锁定某些东西。它非常稳定，并且让它崩溃 + 主管的故障解决方案确实很有效。一切都很容易以编程方式设置，并且不难进行单元测试。

Then there are the excellent add-on modules. The Camel module really plugs in well into Akka and enables such easy development of asynchronous services with configurable endpoints.

然后是优秀的附加模块。Camel 模块确实可以很好地插入 Akka，并支持使用可配置端点轻松开发异步服务。

I'm very happy with the framework and it is becoming a defacto standard for the connected systems that we build.

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

回答by tylerweir

If you abstract the chat server up a level, then you get the answer.

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

Akka provides a messaging system that is akin to Erlang's "let it crash" mentality.

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

So examples are things that need varying levels of durability and reliability of messaging:

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

• Chat server
• Network layer for an MMO
• Financial data pump
• Notification system for an iPhone/mobile/whatever app
• REST Server
• Maybe something akin to WebMachine (guess)

• 聊天服务器
• MMO 的网络层
• 金融数据泵
• iPhone/手机/任何应用程序的通知系统
• 休息服务器
• 也许类似于 WebMachine（猜测）

The nice things about Akka are the choices it affords for persistence, it's STM implementation, REST server and fault-tolerance.

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

Don't get annoyed by the example of a chat server, think of it as an example of a certain class of solution.

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

With all their excellent documentation, I feel like a gap is this exact question, use-cases and examples. Keeping in mind the examples are non-trivial.

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

(Written with only experience of watching videos and playing with the source, I have implemented nothing using akka.)

（仅凭观看视频和播放源的经验编写，我没有使用 akka 实现任何内容。）

回答by Wade Arnold

An example of how we use it would be on a priority queue of debit/credit card transactions. We have millions of these and the effort of the work depends on the input string type. If the transaction is of type CHECK we have very little processing but if it is a point of sale then there is lots to do such as merge with meta data (category, label, tags, etc) and provide services (email/sms alerts, fraud detection, low funds balance, etc). Based on the input type we compose classes of various traits (called mixins) necessary to handle the job and then perform the work. All of these jobs come into the same queue in realtime mode from different financial institutions. Once the data is cleansed it is sent to different data stores for persistence, analytics, or pushed to a socket connection, or to Lift comet actor. Working actors are constantly self load balancing the work so that we can process the data as fast as possible. We can also snap in additional services, persistence models, and stmfor critical decision points.

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

The Erlang OTP style message passing on the JVM makes a great system for developing realtime systems on the shoulders of existing libraries and application servers.

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

Akka allows you to do message passing like you would in a traditional esbbut with speed! It also gives you tools in the framework to manage the vast amount of actor pools, remote nodes, and fault tolerance that you need for your solution.

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

回答by Viktor Klang

Disclaimer: I am the PO for Akka

免责声明：我是 Akka 的 PO

Besides offering a concurrency smorgasbord that is much simpler to reason about and to get correct (actors, agents, dataflow concurrency) and with concurrency control in the form of STM.

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

Here are some use-cases you might consider:

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

1. Transaction processing (online gaming, finance, statistics, betting, social media, telecom, ...)
   • scale up, scale out, fault-tolerance / HA
2. Service backend (any industry, any app)
   • service REST, SOAP, cometd etc
   • act as message hub / integration layer
   • scale up, scale out, fault-tolerance / HA
3. Snap-in concurrency/parallelism ( any app )
   • Correct
   • Simple to work with and understand
   • Just add the jars to your existing JVM project (use Scala, Java, Groovy or JRuby)
4. Batch processing ( any industry )
   • Camel integration to hook up with batch data sources
   • Actors divide and conquer the batch workloads
5. Communications hub ( telecom, web media, mobile media )
   • scale up, scale out, fault-tolerance / HA
6. Game server (online gaming, betting)
   • scale up, scale out, fault-tolerance / HA
7. BI/datamining/general purpose crunching
   • scale up, scale out, fault-tolerance / HA
8. insert other nice use cases here

1. 交易处理（在线游戏、金融、统计、博彩、社交媒体、电信……）
   • 纵向扩展、横向扩展、容错/HA
2. 服务后端（任何行业、任何应用）
   • 服务 REST、SOAP、cometd 等
   • 充当消息中心/集成层
   • 纵向扩展、横向扩展、容错/HA
3. 管理单元并发/并行（任何应用程序）
   • 正确的
   • 易于使用和理解
   • 只需将 jar 添加到您现有的 JVM 项目中（使用 Scala、Java、Groovy 或 JRuby）
4. 批处理（任何行业）
   • Camel 集成以连接批处理数据源
   • Actor 分而治之
5. 通讯枢纽（电信、网络媒体、移动媒体）
   • 纵向扩展、横向扩展、容错/HA
6. 游戏服务器（在线游戏、投注）
   • 纵向扩展、横向扩展、容错/HA
7. BI/数据挖掘/通用处理
   • 纵向扩展、横向扩展、容错/HA
8. 在此处插入其他不错的用例

回答by Luciano Fiandesio

We are using Akka in a large scale Telco project (unfortunately I can't disclose a lot of details). Akka actors are deployed and accessed remotely by a web application. In this way, we have a simplified RPC model based on Google protobuffer and we achieve parallelism using Akka Futures. So far, this model has worked brilliantly. One note: we are using the Java API.

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

回答by Daniel Ribeiro

I've recently implementedthe canonical map-reduce example in Akka: Word count. So it's one use case of Akka: better performance. It was more of a experiment of JRuby and Akka's actorsthan anything else, but it also shows that Akka is not Scala or Java only: it works on all languages on top of JVM.

我最近在 Akka: Word count 中实现了规范的 map-reduce 示例。所以这是 Akka 的一个用例：更好的性能。它更像是JRuby 和 Akka 演员的实验，而不是其他任何东西，但它也表明 Akka 不仅仅是 Scala 或 Java：它适用于 JVM 之上的所有语言。

回答by Matthias L. Jugel

We are using akka with its camel plugin to distribute our analysis and trending processing for twimpact.com. We have to process between 50 and 1000 messages per second. In addition to multi-node processing with camel it is also used to distribute work on a single processor to multiple workers for maximum performance. Works quite well, but requires some understanding of how to handle congestions.

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

回答by rossputin

We use Akka in several projects at work, the most interesting of which is related to vehicle crash repair. Primarily in the UK but now expanding to the US, Asia, Australasia and Europe. We use actors to ensure that crash repair information is provided realtime to enable the safe and cost effective repair of vehicles.

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

The question with Akka is really more 'what can't you do with Akka'. Its ability to integrate with powerful frameworks, its powerful abstraction and all of the fault tolerance aspects make it a very comprehensive toolkit.

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

回答by sutanu dalui

I was trying out my hands on Akka (Java api). What I tried was to compare Akka's actor based concurrency model with that of plain Java concurrency model (java.util.concurrent classes).

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

The use case was a simple canonical map reduce implementation of character count. The dataset was a collection of randomly generated strings (400 chars in length), and calculate the number of vowels in them.

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

For Akka I used a BalancedDispatcher(for load balancing amongst threads) and RoundRobinRouter (to keep a limit on my function actors). For Java, I used simple fork join technique (implemented without any work stealing algorithm) that would fork map/reduce executions and join the results. Intermediate results were held in blocking queues to make even the joining as parallel as possible. Probably, if I am not wrong, that would mimic somehow the "mailbox" concept of Akka actors, where they receive messages.

对于 Akka，我使用了 BalancedDispatcher（用于线程之间的负载平衡）和 RoundRobinRouter（以限制我的函数 actor）。对于 Java，我使用了简单的 fork join 技术（在没有任何工作窃取算法的情况下实现），它会 fork map/reduce 执行并连接结果。中间结果保存在阻塞队列中，以使加入尽可能并行。也许，如果我没记错的话，那会以某种方式模仿 Akka 演员的“邮箱”概念，他们在那里接收消息。

Observation: Till medium loads (~50000 string input) the results were comparable, varying slightly in different iterations. However, as I increased my load to ~100000 it would hang the Java solution. I configured the Java solution with 20-30 threads under this condition and it failed in all iterations.

观察：直到中等负载（约 50000 个字符串输入），结果都具有可比性，在不同的迭代中略有不同。但是，当我将负载增加到 ~100000 时，它会挂起 Java 解决方案。我在这种情况下用 20-30 个线程配置了 Java 解决方案，但它在所有迭代中都失败了。

Increasing the load to 1000000, was fatal for Akka as well. I can share the code with anyone interested to have a cross check.

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

So for me, it seems Akka scales out better than traditional Java multithreaded solution. And probably the reason is the under the hood magic of Scala.

所以对我来说，似乎 Akka 比传统的 Java 多线程解决方案更好地扩展。原因可能是 Scala 的幕后魔法。

If I can model a problem domain as an event driven message passing one, I think Akka is a good choice for the JVM.

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

Test performed on: Java version:1.6 IDE: Eclipse 3.7 Windows Vista 32 bit. 3GB ram. Intel Core i5 processor, 2.5 GHz clock speed

测试在：Java 版本：1.6 IDE：Eclipse 3.7 Windows Vista 32 位。3GB 内存。Intel Core i5 处理器，2.5 GHz 时钟速度

Please note, the problem domain used for the test can be debated and I tried to be as much fair as my Java knowledge allowed :-)

请注意，用于测试的问题域是可以辩论的，我试图在我的 Java 知识允许的范围内尽可能公平:-)

回答by piotrga

We use Akka to process REST calls asynchronously - together with async web server (Netty-based) we can achieve 10 fold improvement on the number of users served per node/server, comparing to traditional thread per user request model.

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

Tell it to your boss that your AWS hosting bill is going to drop by the factor of 10 and it is a no-brainer! Shh... dont tell it to Amazon though... :)

告诉你的老板，你的 AWS 托管费用将下降 10 倍，这是显而易见的！嘘...不过不要告诉亚马逊... :)