Akka Twitter Storm 英文原文：Akka vs Storm

最近一段时间工作很多都在和Twitter’s Storm打交道，这使我想知道，它和另一个高性能、并发数据处理的框架Akka对比有什么优缺点呢？

关于Akka和Storm？

让我们简单的描述一下两个系统。Storm是一个分布式实时计算系统。在一个Storm集群中，执行拓扑结构，在这个拓扑中进行元组（数据）流进程。每一个拓扑是一个由喷嘴（他产生元组）和螺栓（他负责转化元组）组成。Storm负责集群通讯，容错和通过集群节点分配拓扑。

Akka 是一个构建分布式、并发、容错应用程序的工具集。在Akka应用中，基本结构是一个物件；物件异步的处理消息，并且保证每一个物件在某一个时刻最多运行在一个线程中，这是的同步更加容易。物件也可以远程部署。这儿是一个集群模块，它可以自动处理实现容错和通过集群节点进行物件的分配。

两个系统都大型架构可以处理超大数量的数据。但是在使用时候我们怎么选择呢？

这儿有一个很好的博文论述了这个主题，但是我想跟进一步对他们做个比较：让我们看看两者最基本的结构有什么不同？

基本比较

首先，Storm最基本的数据部分是一个元组。一个元组有人以数量的元素构成，每一个元组元素可以是任意的对象，并且实现了序列化。而Akka的最基本单元是消息，消息也可以是任意的对象，同样他应该可被序列化（为了把它送到远程的物件）。所以在概念上两者基本上是一样的。

让我们看看基本的计算单元。在Storm中，拥有组件：螺栓和喷嘴。一个螺栓可以是任意块的代码，可在随后的元组中处理任意的进程。他也可以存储一些动态的数据。例如，累加的结果。同时，螺栓运行在单线程，所以除非你要在你的螺栓中开启一个新的线程，你不用担心并行处理数据的问题。这和物件非常像,不是吗？因此，一个Storm螺栓/喷嘴相当于一个Akka物件。那两者的细节上有上有和异同呢？

物件可以接收任意消息；螺栓可以接收任意的元组。两者都被期望在接收到的数据上做一些处理。两者都有内部状态，包括对并发线程处理的私有的和受保护态

物件和螺栓的不同

一个显著的不同是两者的通讯方式。一个物件可以传递消息给任意的物件，只要有物件的引用（如果没有，一个物件可以通过名称查询出）。物件也可以给消息发送者返回一个回复，说明消息已被处理。Storm处理的过程则是单向的。他不能返回消息。你也不能给任意的螺栓传递消息。你可以把一个元组放入一个命名通道（流），这个通道可以把螺栓发出的消息在所在通道进行广播，在拓扑中定义（螺栓也确认消息，这也是一种通讯的方式，对确认者）

在Storm中，多份螺栓/喷嘴的代码拷贝可以并行执行（取决于并行设置）。这相当于一系列（可能是远程的）物件，但是在前端有一个负载均衡的物件；Akka中的概念叫路由。关于元组如何被传递给螺栓实例有很多中的算法，包括随机、一个域的相容哈希等。这和Akka中的多种路由选择类似（循环、消息相容哈希）

在螺栓和物件在构成权重上有有所不同。在Akka，并列地存在这很多物件（可以到数百万）。在Storm中，预期的螺栓数量是很小的。没有任何的理由限制这个数量，这实际上是由设计初衷导致的。同时，Akka物件通常都是共享线程的。而螺栓实例却是独享线程。

其他特性

Storm 也有一个重要的特性，有在Akka中所没有的：保证消息传递。Storm遍历整个元组数，这个数的根节点都是嘴发出的元组。如果所有的元组还没有被确认，元组将被重新遍历。

同时，Storm的集群管理也是更先进（自动容错，集群中自动负载均衡；基于Zookeeper）。一个好消息是Akka的集群模块将会增加这些特性。

最后，Storm的层状通讯、拓扑是静态的，并且是事先定义的。Akka通讯模式可以通过时间转换，并且可以完全动态配置。物件可以传递消息给任何其他物件，也可以送抵到地址（物件引用）。

总而言之，Storm适用于特定范围的用户，而Akka是一个更加通用的工具集。基于Akka可以构建类似Storm的系统，但是相反做法是不可行的（至少可以可以说那将非常的艰难）

亚当

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务