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)
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.
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.
I'm very happy with the framework and it is becoming a defacto standard for the connected systems that we build.
只需将 jar 添加到您现有的 JVM 项目中（使用 Scala， Java、Groovy 或 JRuby）
批处理（任何行业）
Camel 集成以连接批量数据源
参与者划分并克服批量工作负载
通信中心（电信、网络媒体、移动媒体）
纵向扩展、横向扩展、容错/HA
游戏服务器（在线游戏、博彩）
纵向扩展、横向扩展、容错/HA
BI/数据挖掘/通用处理
纵向扩展、横向扩展、容错/HA
在此处插入其他不错的用例
Disclaimer: I am the PO for Akka
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.
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.
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.
Akka allows you to do message passing like you would in a traditional esb but 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.
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.
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... :)
我们正在一个大型电信项目中使用 Akka（不幸的是我无法透露很多细节）。 Akka Actor 由 Web 应用程序远程部署和访问。这样，我们就有了一个基于 Google protobuffer 的简化 RPC 模型，并使用 Akka Futures 实现了并行性。 到目前为止，这个模型运作良好。需要注意的是：我们使用的是 Java API。
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.
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.
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)
The nice things about Akka are the choices it affords for persistence, it's STM implementation, REST server and fault-tolerance.
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.)
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.
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.
自从 Google Reader 关闭后，我开始使用 RSS 阅读器，当然是使用 Akka。对我来说，这都是关于封装服务的。结论：Actor 模型本身是您应该首先采用的，Akka 是一个非常可靠的框架，可以帮助您实现它，并在此过程中您将获得很多好处。
You can use Akka for several different kinds of things.
I was working on a website, where I migrated the technology stack to Scala and Akka. We used it for pretty much everything that happened on the website. Even though you might think a Chat example is bad, all are basically the same:
Live updates on the website (e.g. views, likes, ...)
Showing live user comments
Notification services
Search and all other kinds of services
Especially the live updates are easy since they boil down to what a Chat example ist. The services part is another interesting topic because you can simply choose to use remote actors and even if your app is not clustered, you can deploy it to different machines with ease.
I am also using Akka for a PCB autorouter application with the idea of being able to scale from a laptop to a data center. The more power you give it, the better the result will be. This is extremely hard to implement if you try to use usual concurrency because Akka gives you also location transparency.
Currently as a free time project, I am building a web framework using only actors. Again the benefits are scalability from a single machine to an entire cluster of machines. Besides, using a message driven approach makes your software service oriented from the start. You have all those nice components, talking to each other but not necessarily knowing each other, living on the same machine, not even in the same data center.
And since Google Reader shut down I started with a RSS reader, using Akka of course. It is all about encapsulated services for me. As a conclusion: The actor model itself is what you should adopt first and Akka is a very reliable framework helping you to implement it with a lot of benefits you will receive along the way.
测试进行于： Java版本：1.6 集成开发环境：Eclipse 3.7 Windows Vista 32 位。 3GB 内存。 Intel Core i5 处理器，2.5 GHz 时钟速度
请注意，用于测试的问题域可以进行辩论，我尽力在我的 Java 知识允许的范围内做到公平:-)
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).
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.
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.
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.
Increasing the load to 1000000, was fatal for Akka as well. I can share the code with anyone interested to have a cross check.
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.
If I can model a problem domain as an event driven message passing one, I think Akka is a good choice for the 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
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 :-)
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.
We use Akka in spoken dialog systems (primetalk). Both internally and externally. In order to simultaneously run a lot of telephony channels on a single cluster node it is obviously necessary to have some multithreading framework. Akka works just perfect. We have previous nightmare with the java-concurrency. And with Akka it is just like a swing — it simply works. Robust and reliable. 24*7, non-stop.
Inside a channel we have real-time stream of events that are processed in parallel. In particular: - lengthy automatic speech recognition — is done with an actor; - audio output producer that mixes a few audio sources (including synthesized speech); - text-to-speech conversion is a separate set of actors shared between channels; - semantic and knowledge processing.
To make interconnections of complex signal processing we use SynapseGrid. It has the benefit of compile-time checking of the DataFlow in the complex actor systems.
I've recently implemented the 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 actors than anything else, but it also shows that Akka is not Scala or Java only: it works on all languages on top of JVM.
发布评论
评论（12）
到目前为止，我已经在两个实际项目中非常成功地使用了它。两者都属于近实时交通信息领域（高速公路上的汽车交通），分布在多个节点上，集成多方之间的消息，可靠的后端系统。我还不能自由地透露客户的具体情况，当我得到同意后，也许可以将其添加为参考。
Akka 确实完成了这些项目，尽管我们是在 0.7 版本时就开始的。 （顺便说一下，我们正在使用 scala）
最大的优点之一是，您可以轻松地用参与者和消息组成一个系统，几乎不需要样板，它的扩展性非常好，无需手动滚动线程的所有复杂性，您可以得到对象之间的异步消息传递几乎是免费的。
它非常适合对任何类型的异步消息处理进行建模。与任何其他风格相比，我更喜欢用这种风格编写任何类型的（网络）服务系统。 （您是否尝试过使用 JAX-WS 编写异步 Web 服务（服务器端）？这需要大量的工作）。因此，我想说任何不想挂在其组件之一上的系统，因为所有内容都是使用同步方法隐式调用的，并且一个组件正在锁定某些内容。它非常稳定，并且“让它崩溃+主管”的故障解决方案确实效果很好。一切都很容易以编程方式设置，并且单元测试并不困难。
然后是优秀的附加模块。
Camel 模块确实可以很好地插入到 Akka 中，并且可以轻松开发具有可配置端点的异步服务。
我对这个框架非常满意，它正在成为我们构建的互联系统的事实上的标准。
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)
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.
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.
I'm very happy with the framework and it is becoming a defacto standard for the connected systems that we build.
免责声明：我是 Akka 的 PO，
除了提供一个更容易推理和获得正确性的并发大杂烩（参与者、代理、数据流并发）以及 STM 形式的并发控制。
以下是您可能会考虑的一些用例：
游戏、金融、统计、
博彩、社交媒体、电信……）
Java、Groovy 或 JRuby）
Disclaimer: I am the PO for Akka
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.
Here are some use-cases you might consider:
gaming, finance, statistics,
betting, social media, telecom, ...)
Java, Groovy or JRuby)
我们如何使用它的一个例子是借记卡/信用卡交易的优先级队列。我们有数百万个这样的数据，工作量取决于输入字符串类型。如果交易是 CHECK 类型，我们几乎不需要处理，但如果是销售点，则有很多工作要做，例如与元数据（类别、标签、标记等）合并并提供服务（电子邮件/短信提醒、欺诈检测、低资金余额等）。
根据输入类型，我们构建处理工作所需的各种特征（称为 mixin）的类，然后执行工作。所有这些工作都以实时模式从不同的金融机构进入同一个队列。一旦数据被清理，它就会被发送到不同的数据存储以进行持久化、分析，或推送到套接字连接，或Lift comet actor。工作参与者不断地自我负载平衡工作，以便我们能够尽快处理数据。我们还可以嵌入其他服务、持久性模型和 stm 关键决策点。
在 JVM 上传递的 Erlang OTP 风格的消息为在现有库和应用程序服务器的基础上开发实时系统提供了一个出色的系统。
Akka 允许您像在传统 esb< 中一样进行消息传递/a> 但速度要快！它还为您提供框架中的工具来管理解决方案所需的大量参与者池、远程节点和容错能力。
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.
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.
Akka allows you to do message passing like you would in a traditional esb but 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 异步处理 REST 调用 - 与异步 Web 服务器（基于 Netty）一起，与传统的每个用户请求线程模型相比，我们可以将每个节点/服务器服务的用户数量提高 10 倍。
告诉你的老板，你的 AWS 托管费用将下降 10 倍，这是理所当然的事情！嘘...不过不要告诉亚马逊...:)
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.
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... :)
我们正在一个大型电信项目中使用 Akka（不幸的是我无法透露很多细节）。
Akka Actor 由 Web 应用程序远程部署和访问。这样，我们就有了一个基于 Google protobuffer 的简化 RPC 模型，并使用 Akka Futures 实现了并行性。
到目前为止，这个模型运作良好。需要注意的是：我们使用的是 Java API。
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 提供了一个类似于 Erlang 的“让它崩溃”心态的消息系统。
因此，例子是需要不同级别的消息传递持久性和可靠性的东西：
Akka 的好处是它为持久性提供的选择，它是 STM 实现、REST 服务器和容错。
不要对聊天服务器的示例感到恼火，将其视为某类解决方案的示例。
尽管他们提供了出色的文档，但我觉得差距就在于这个确切的问题、用例和示例。请记住，这些示例并不简单。
（仅根据观看视频和使用源代码的经验编写，我没有使用 akka 实现任何内容。）
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.
So examples are things that need varying levels of durability and reliability of messaging:
The nice things about Akka are the choices it affords for persistence, it's STM implementation, REST server and fault-tolerance.
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，其中最有趣的是与车辆碰撞修复相关。主要在英国，但现在扩展到美国、亚洲、澳大利亚和欧洲。
我们使用参与者来确保实时提供碰撞修复信息，以实现安全且具有成本效益的车辆修复。
Akka 的问题实际上更多是“你不能用 Akka 做什么”。它与强大框架集成的能力、强大的抽象和所有容错方面使其成为一个非常全面的工具包。
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.
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 用于多种不同类型的事情。
我当时正在做一个网站，我将技术栈迁移到了 Scala 和 Akka。我们几乎用它来处理网站上发生的所有事情。即使您可能认为聊天示例很糟糕，但所有内容基本上都是相同的：
尤其是实时更新很容易，因为它们归结为聊天示例。服务部分是另一个有趣的主题，因为您可以简单地选择使用远程参与者，即使您的应用程序没有集群，您也可以轻松地将其部署到不同的机器上。
我还将 Akka 用于 PCB 自动布线应用程序，其想法是能够从笔记本电脑扩展到数据中心。你给予它的力量越多，结果就越好。如果您尝试使用通常的并发性，这是非常难以实现的，因为 Akka 还为您提供位置透明性。
目前，作为一个空闲时间项目，我正在仅使用参与者构建一个网络框架。同样，好处是从单台机器到整个机器集群的可扩展性。此外，使用消息驱动的方法使您的软件从一开始就面向服务。你拥有所有这些很好的组件，可以相互交谈，但不一定相互了解，生活在同一台机器上，甚至不在同一个数据中心。
自从 Google Reader 关闭后，我开始使用 RSS 阅读器，当然是使用 Akka。对我来说，这都是关于封装服务的。结论：Actor 模型本身是您应该首先采用的，Akka 是一个非常可靠的框架，可以帮助您实现它，并在此过程中您将获得很多好处。
You can use Akka for several different kinds of things.
I was working on a website, where I migrated the technology stack to Scala and Akka. We used it for pretty much everything that happened on the website. Even though you might think a Chat example is bad, all are basically the same:
Especially the live updates are easy since they boil down to what a Chat example ist. The services part is another interesting topic because you can simply choose to use remote actors and even if your app is not clustered, you can deploy it to different machines with ease.
I am also using Akka for a PCB autorouter application with the idea of being able to scale from a laptop to a data center. The more power you give it, the better the result will be. This is extremely hard to implement if you try to use usual concurrency because Akka gives you also location transparency.
Currently as a free time project, I am building a web framework using only actors. Again the benefits are scalability from a single machine to an entire cluster of machines. Besides, using a message driven approach makes your software service oriented from the start. You have all those nice components, talking to each other but not necessarily knowing each other, living on the same machine, not even in the same data center.
And since Google Reader shut down I started with a RSS reader, using Akka of course. It is all about encapsulated services for me. As a conclusion: The actor model itself is what you should adopt first and Akka is a very reliable framework helping you to implement it with a lot of benefits you will receive along the way.
我正在尝试使用 Akka（Java api）。我尝试将 Akka 基于 actor 的并发模型与普通 Java 并发模型（java.util.concurrent 类）进行比较。
该用例是一个简单的规范映射减少字符计数的实现。该数据集是随机生成的字符串（长度为 400 个字符）的集合，并计算其中的元音数量。
对于 Akka，我使用了 BalancedDispatcher（用于线程之间的负载平衡）和 RoundRobinRouter（以限制我的函数参与者）。对于 Java，我使用了简单的 fork join 技术（在没有任何工作窃取算法的情况下实现），该技术将 fork map/reduce 执行并连接结果。中间结果保存在阻塞队列中，以使连接尽可能并行。如果我没记错的话，这可能会以某种方式模仿 Akka Actor 的“邮箱”概念，他们在其中接收消息。
观察：
直到中等负载（~50000 个字符串输入），结果都是可比的，在不同的迭代中略有不同。然而，当我将负载增加到 ~100000 时，它会挂起 Java 解决方案。在这种情况下，我将 Java 解决方案配置为 20-30 个线程，但在所有迭代中都失败了。
将负载增加到 1000000，对于 Akka 来说也是致命的。我可以与任何有兴趣进行交叉检查的人分享代码。
所以对我来说，Akka 的扩展能力似乎比传统的 Java 多线程解决方案更好。原因很可能是 Scala 背后的魔力。
如果我可以将问题域建模为事件驱动的消息传递域，我认为 Akka 对于 JVM 来说是一个不错的选择。
测试进行于：
Java版本：1.6
集成开发环境：Eclipse 3.7
Windows Vista 32 位。 3GB 内存。 Intel Core i5 处理器，2.5 GHz 时钟速度
请注意，用于测试的问题域可以进行辩论，我尽力在我的 Java 知识允许的范围内做到公平:-)
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).
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.
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.
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.
Increasing the load to 1000000, was fatal for Akka as well. I can share the code with anyone interested to have a cross check.
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.
If I can model a problem domain as an event driven message passing one, I think Akka is a good choice for the 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
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 :-)
我们使用 akka 及其 Camel 插件来分发对 twimpact.com 的分析和趋势处理。我们每秒必须处理 50 到 1000 条消息。除了使用骆驼进行多节点处理之外，它还用于将单个处理器上的工作分配给多个工作人员，以获得最大性能。效果很好，但需要了解如何处理拥塞。
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 (primetalk)。无论是内部还是外部。为了在单个集群节点上同时运行大量电话通道，显然需要一些多线程框架。 Akka 工作得非常完美。我们之前曾经历过关于 java 并发的噩梦。对于 Akka，它就像秋千一样 — 简单有效。坚固可靠。 7*24小时，不间断。
在通道内，我们有并行处理的实时事件流。尤其：
- 冗长的自动语音识别——由演员完成；
- 混合一些音频源（包括合成语音）的音频输出生成器；
- 文本到语音转换是在通道之间共享的一组单独的参与者；
- 语义和知识处理。
为了实现复杂信号处理的互连，我们使用 SynapseGrid。它的优点是可以在复杂的参与者系统中对数据流进行编译时检查。
We use Akka in spoken dialog systems (primetalk). Both internally and externally. In order to simultaneously run a lot of telephony channels on a single cluster node it is obviously necessary to have some multithreading framework. Akka works just perfect. We have previous nightmare with the java-concurrency. And with Akka it is just like a swing — it simply works. Robust and reliable. 24*7, non-stop.
Inside a channel we have real-time stream of events that are processed in parallel. In particular:
- lengthy automatic speech recognition — is done with an actor;
- audio output producer that mixes a few audio sources (including synthesized speech);
- text-to-speech conversion is a separate set of actors shared between channels;
- semantic and knowledge processing.
To make interconnections of complex signal processing we use SynapseGrid. It has the benefit of compile-time checking of the DataFlow in the complex actor systems.
我最近在 Akka 中实现了规范的 map-reduce 示例：字数统计。所以这是 Akka 的一个用例：更好的性能。这更像是 JRuby 和 Akka 的参与者比其他任何东西都重要，但这也表明 Akka 不仅仅是 Scala 或 Java：它适用于 JVM 之上的所有语言。
I've recently implemented the 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 actors than anything else, but it also shows that Akka is not Scala or Java only: it works on all languages on top of JVM.