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

我在一个网站上工作，在那里我将技术堆栈迁移到Scala和Akka。我们用它来处理网站上发生的几乎所有事情。尽管你可能认为一个聊天的例子很糟糕，但基本上都是一样的:

网站上的实时更新(例如，浏览量，点赞，…) 显示实时用户评论 通知服务 搜索和其他各种服务

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

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

目前作为一个空闲时间的项目，我正在构建一个只使用演员的web框架。同样，它的好处是从一台机器到整个机器集群的可伸缩性。此外，使用消息驱动方法可以使您的软件从一开始就面向服务。您拥有所有这些良好的组件，它们彼此通信，但不一定相互了解，它们位于同一台机器上，甚至不在同一个数据中心中。

自从谷歌阅读器关闭后，我开始使用RSS阅读器，当然使用Akka。对我来说，这完全是关于封装的服务。总之:参与者模型本身是您首先应该采用的，Akka是一个非常可靠的框架，可以帮助您实现它，并在此过程中获得许多好处。

免责声明:我是Akka的采购订单

此外，它还提供了一个更容易推理和纠正的并发大杂烩(参与者、代理、数据流并发)，并以STM的形式进行并发控制。

下面是一些你可以考虑的用例:

Transaction processing (online gaming, finance, statistics, betting, social media, telecom, ...) scale up, scale out, fault-tolerance / HA Service backend (any industry, any app) service REST, SOAP, cometd etc act as message hub / integration layer scale up, scale out, fault-tolerance / HA 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) Batch processing ( any industry ) Camel integration to hook up with batch data sources Actors divide and conquer the batch workloads Communications hub ( telecom, web media, mobile media ) scale up, scale out, fault-tolerance / HA Game server (online gaming, betting) scale up, scale out, fault-tolerance / HA BI/datamining/general purpose crunching scale up, scale out, fault-tolerance / HA insert other nice use cases here

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

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

我正在试用Akka (Java api)。我所尝试的是比较Akka的基于参与者的并发模型和普通Java并发模型(Java .util。并发类)。

这个用例是一个简单的规范映射减少字符计数的实现。数据集是随机生成的字符串(长度为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.

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

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

所以对我来说，Akka似乎比传统的Java多线程解决方案更好。原因可能是Scala的底层魔力。

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

测试对象: Java版本:1.6 IDE: Eclipse 3.7 Windows Vista 32位。3 gb ram。英特尔酷睿i5处理器，2.5 GHz时钟速度

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

我们使用Akka来异步处理REST调用——与异步web服务器(基于net)一起，与传统的每个用户请求线程模型相比，我们可以在每个节点/服务器服务的用户数量上实现10倍的提高。

告诉你的老板，你的AWS托管费用将下降10倍，这是一个不用动脑筋的事情!嘘……不过别告诉亚马逊…：）

到目前为止，我已经在两个实际项目中非常成功地使用了它。两者都在接近实时的交通信息领域(就像高速公路上的汽车一样)，分布在几个节点上，集成各方之间的消息，可靠的后端系统。我现在还不能透露客户的具体情况，当我得到批准的时候，也许可以把它作为参考。

Akka确实完成了这些项目，尽管我们在0.7版本时就开始了。(顺便说一下，我们正在使用scala)

最大的优势之一是，你可以轻松地用角色和消息组成一个系统，几乎没有样板，它的伸缩性非常好，没有手摇线程的复杂性，你几乎可以免费地在对象之间传递异步消息。

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.

还有一些优秀的附加模块。 Camel模块可以很好地插入到Akka中，并且可以使用可配置的端点轻松开发异步服务。

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