我听过很多关于Akka框架(Java/Scala服务平台)的赞不绝口,但到目前为止,还没有看到很多实际用例的例子。因此,我很有兴趣了解开发人员如何成功地使用它。
只有一个限制:请不要包括写聊天服务器的情况。 (为什么?因为这已经被过度用作许多类似事情的例子)
我听过很多关于Akka框架(Java/Scala服务平台)的赞不绝口,但到目前为止,还没有看到很多实际用例的例子。因此,我很有兴趣了解开发人员如何成功地使用它。
只有一个限制:请不要包括写聊天服务器的情况。 (为什么?因为这已经被过度用作许多类似事情的例子)
当前回答
免责声明:我是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角色由web应用程序远程部署和访问。这样,我们就有了一个基于谷歌原型缓冲区的简化RPC模型,并使用Akka Futures实现了并行。 到目前为止,这种模式运行得非常出色。注意:我们使用的是Java API。
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 (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的采购订单
此外,它还提供了一个更容易推理和纠正的并发大杂烩(参与者、代理、数据流并发),并以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