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

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

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

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

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

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

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

(仅凭观看视频和玩源代码的经验编写，我没有使用akka实现任何东西。)

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

免责声明:我是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 (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中实现了规范的map-reduce示例:Word count。所以这是Akka的一个用例:更好的性能。它更像是JRuby和Akka的参与者的一个实验，但它也表明Akka不仅仅是Scala或Java:它可以在JVM之上的所有语言上工作。

我们正在一个大型电信项目中使用Akka(不幸的是，我不能透露太多细节)。 Akka角色由web应用程序远程部署和访问。这样，我们就有了一个基于谷歌原型缓冲区的简化RPC模型，并使用Akka Futures实现了并行。 到目前为止，这种模式运行得非常出色。注意:我们使用的是Java API。