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

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

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

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

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

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

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

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

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

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 stm for critical decision points.

在JVM上传递的Erlang OTP风格的消息对于在现有库和应用程序服务器的肩膀上开发实时系统来说是一个很棒的系统。

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

免责声明:我是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提供了一个类似于Erlang的“让它崩溃”的消息传递系统。

例如，需要不同级别的持久性和可靠性的消息传递:

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

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

不要被聊天服务器的例子惹恼，把它看作是某一类解决方案的例子。

在他们所有优秀的文档中，我觉得这个确切的问题、用例和示例存在差距。请记住，这些例子不是简单的。

(仅凭观看视频和玩源代码的经验编写，我没有使用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知识允许的范围内尽可能地公平:-)