1.什么是storm

       Storm是Twitter开源的分布式实时大数据处理框架，被业界称为实时版Hadoop。随着越来越多的场景对Hadoop的MapReduce高延迟无法容忍，比如网站统计、推荐系统、预警系统、金融系统(高频交易、股票)等等，大数据实时处理解决方案（流计算）的应用日趋广泛，目前已是分布式技术领域最新爆发点，而Storm更是流计算技术中的佼佼者和主流。

       按照storm作者的说法，Storm对于实时计算的意义类似于Hadoop对于批处理的意义。Hadoop提供了map、reduce原语，使我们的批处理程序变得简单和高效。同样，Storm也为实时计算提供了一些简单高效的原语，而且Storm的Trident是基于Storm原语更高级的抽象框架，类似于基于Hadoop的Pig框架，让开发更加便利和高效。

2.storm应用场景

     推荐系统（实时推荐，根据下单或加入购物车推荐相关商品）、金融系统、预警系统、网站统计（实时销量、流量统计，如淘宝双11效果图）、交通路况实时系统等等。

3.storm的一些特性

    1.适用场景广泛： storm可以实时处理消息和更新DB，对一个数据量进行持续的查询并返回客户端（持续计算），对一个耗资源的查询作实时并行化的处理(分布式方法调用，即DRPC），storm的这些基础API可以满足大量的场景。

    2. 可伸缩性高:  Storm的可伸缩性可以让storm每秒可以处理的消息量达到很高。扩展一个实时计算任务，你所需要做的就是加机器并且提高这个计算任务的并行度 。Storm使用ZooKeeper来协调集群内的各种配置使得Storm的集群可以很容易的扩展。

    3. 保证无数据丢失： 实时系统必须保证所有的数据被成功的处理。 那些会丢失数据的系统的适用场景非常窄， 而storm保证每一条消息都会被处理， 这一点和S4相比有巨大的反差。

    4. 异常健壮： storm集群非常容易管理，轮流重启节点不影响应用。

    5. 容错性好：在消息处理过程中出现异常， storm会进行重试

    6. 语言无关性： Storm的topology和消息处理组件(Bolt)可以用任何语言来定义， 这一点使得任何人都可以使用storm.

4.storm集群结构

Nimbus 和Supervisors 之间所有的协调工作是通过 一个Zookeeper 集群。
Nimbus进程和 Supervisors 进程是无法直接连接，并且是无状态的;  所有的状态维持在Zookeeper中或保存在本地磁盘上。

意味着你可以 kill -9 Nimbus 或Supervisors 进程，而不需要做备份。

这种设计导致storm集群具有令人难以置信的稳定性，并且无耦合。

5.storm工作原理

     Nimbus 负责在集群分发的代码，topo只能在nimbus机器上提交，将任务分配给其他机器，和故障监测。

     Supervisor，监听分配给它的节点，根据Nimbus 的委派在必要时启动和关闭工作进程。 每个工作进程执行topology 的一个子集。一个运行中的topology 由很多运行在很多机器上的工作进程组成。

    在Storm中有对于流stream的抽象，流是一个不间断的无界的连续tuple，注意Storm在建模事件流时，把流中的事件抽象为tuple即元组

     Storm认为每个stream都有一个源，也就是原始元组的源头，叫做Spout（管口）

     处理stream内的tuple，抽象为Bolt，bolt可以消费任意数量的输入流，只要将流方向导向该bolt，同时它也可以发送新的流给其他bolt使用，这样一来，只要打开特定的spout再将spout中流出的tuple导向特定的bolt，bolt又对导入的流做处理后再导向其他bolt或者目的地。

      可以认为spout就是水龙头，并且每个水龙头里流出的水是不同的，我们想拿到哪种水就拧开哪个水龙头，然后使用管道将水龙头的水导向到一个水处理器（bolt），水处理器处理后再使用管道导向另一个处理器或者存入容器中。

        为了增大水处理效率，我们很自然就想到在同个水源处接上多个水龙头并使用多个水处理器，这样就可以提高效率。

这是一张有向无环图，Storm将这个图抽象为Topology(拓扑)，Topo就是storm的Job抽象概念，一个拓扑就是一个流转换图

图中每个节点是一个spout或者bolt，每个spout或者bolt发送元组到下一级组件。

而Spout到单个Bolt有6种流分组策略。

6.Topology

      Storm将流中元素抽象为tuple，一个tuple就是一个值列表value list，list中的每个value可以是任意可序列化的类型。拓扑的每个节点都要说明它所发射出的元组的字段的name，其他节点只需要订阅该name就可以接收处理。

7.storm相关概念

Streams：消息流

       消息流是一个没有边界的tuple序列，而这些tuples会被以一种分布式的方式并行创建和处理。 每个tuple可以包含多列，字段类型可以是： integer, long, short, byte, string, double, float, boolean和byte array。 你还可以自定义类型 — 只要你实现对应的序列化器。

Spouts：消息源

      Spouts是topology消息生产者。Spout从一个外部源(消息队列)读取数据向topology发出tuple。 消息源Spouts可以是可靠的也可以是不可靠的。一个可靠的消息源可以重新发射一个处理失败的tuple， 一个不可靠的消息源Spouts不会。

      Spout类的方法nextTuple不断发射tuple到topology，storm在检测到一个tuple被整个topology成功处理的时候调用ack, 否则调用fail。

      storm只对可靠的spout调用ack和fail。

Bolts：消息处理者

      消息处理逻辑被封装在bolts里面，Bolts可以做很多事情： 过滤， 聚合， 查询数据库等。

      Bolts可以简单的做消息流的传递。复杂的消息流处理往往需要很多步骤， 从而也就需要经过很多Bolts。第一级Bolt的输出可以作为下一级Bolt的输入。而Spout不能有一级。

      Bolts的主要方法是execute（死循环）连续处理传入的tuple，成功处理完每一个tuple调用OutputCollector的ack方法，以通知storm这个tuple被处理完成了。当处理失败时，可以调fail方法通知Spout端可以重新发送该tuple。

     流程是： Bolts处理一个输入tuple, 然后调用ack通知storm自己已经处理过这个tuple了。storm提供了一个IBasicBolt会自动调用ack。

     Bolts使用OutputCollector来发射tuple到下一级Blot。

Apache Storm简介

什么是Apache Storm？

Apache Storm是一个分布式实时大数据处理系统。Storm设计用于在容错和水平可扩展方法中处理大量数据。它是一个流数据框架，具有最高的摄取率。虽然Storm是无状态的，它通过Apache ZooKeeper管理分布式环境和集群状态。它很简单，您可以并行地对实时数据执行各种操作。

Apache Storm继续成为实时数据分析的领导者。Storm易于设置和操作，并且它保证每个消息将通过拓扑至少处理一次。

Apache Storm vs Hadoop

基本上Hadoop和Storm框架用于分析大数据。两者互补，在某些方面有所不同。Apache Storm执行除持久性之外的所有操作，而Hadoop在所有方面都很好，但滞后于实时计算。下表比较了Storm和Hadoop的属性。

Storm	Hadoop
实时流处理	批量处理
无状态	有状态
主/从架构与基于ZooKeeper的协调。主节点称为nimbus，从属节点是主管。	具有/不具有基于ZooKeeper的协调的主 - 从结构。主节点是作业跟踪器，从节点是任务跟踪器。
Storm流过程在集群上每秒可以访问数万条消息。	Hadoop分布式文件系统（HDFS）使用MapReduce框架来处理大量的数据，需要几分钟或几小时。
Storm拓扑运行直到用户关闭或意外的不可恢复故障。	MapReduce作业按顺序执行并最终完成。
两者都是分布式和容错的
如果nimbus / supervisor死机，重新启动使它从它停止的地方继续，因此没有什么受到影响。	如果JobTracker死机，所有正在运行的作业都会丢失。

使用Apache Storm的例子

Apache Storm对于实时大数据流处理非常有名。因此，大多数公司都将Storm用作其系统的一个组成部分。一些值得注意的例子如下 -

Twitter - Twitter正在使用Apache Storm作为其“发布商分析产品”。 “发布商分析产品”处理Twitter平台中的每个tweets和点击。 Apache Storm与Twitter基础架构深度集成。

NaviSite - NaviSite正在使用Storm进行事件日志监控/审计系统。系统中生成的每个日志都将通过Storm。Storm将根据配置的正则表达式集检查消息，如果存在匹配，那么该特定消息将保存到数据库。

Wego - Wego是位于新加坡的旅行元搜索引擎。旅行相关数据来自世界各地的许多来源，时间不同。Storm帮助Wego搜索实时数据，解决并发问题，并为最终用户找到最佳匹配。

 

Apache Storm优势

下面是Apache Storm提供的好处列表：

• Storm是开源的，强大的，用户友好的。它可以用于小公司和大公司。

• Storm是容错的，灵活的，可靠的，并且支持任何编程语言。

• 允许实时流处理。

• Storm是令人难以置信的快，因为它具有巨大的处理数据的力量。

• Storm可以通过线性增加资源来保持性能，即使在负载增加的情况下。它是高度可扩展的。

• Storm在几秒钟或几分钟内执行数据刷新和端到端传送响应取决于问题。它具有非常低的延迟。

• Storm有操作智能。

• Storm提供保证的数据处理，即使群集中的任何连接的节点死或消息丢失。

Apache Storm核心概念

Apache Storm从一端读取??实时数据的原始流，并将其传递通过一系列小处理单元，并在另一端输出处理/有用的信息。

下图描述了Apache Storm的核心概念。

现在让我们仔细看看Apache Storm的组件 -

组件	描述
Tuple	Tuple是Storm中的主要数据结构。它是有序元素的列表。默认情况下，Tuple支持所有数据类型。通常，它被建模为一组逗号分隔的值，并传递到Storm集群。
Stream	流是元组的无序序列。
Spouts	流的源。通常，Storm从原始数据源（如Twitter Streaming API，Apache Kafka队列，Kestrel队列等）接受输入数据。否则，您可以编写spouts以从数据源读取数据。“ISpout”是实现spouts的核心接口，一些特定的接口是IRichSpout，BaseRichSpout，KafkaSpout等。
Bolts	Bolts是逻辑处理单元。Spouts将数据传递到Bolts和Bolts过程，并产生新的输出流。Bolts可以执行过滤，聚合，加入，与数据源和数据库交互的操作。Bolts接收数据并发射到一个或多个Bolts。 “IBolt”是实现Bolts的核心接口。一些常见的接口是IRichBolt，IBasicBolt等。

让我们来看一个“Twitter分析”的实时示例，看看如何在Apache Storm中建模。下图描述了结构。

“Twitter分析”的输入来自Twitter Streaming API。Spout将使用Twitter Streaming API读取用户的tweets，并作为元组流输出。来自spout的单个元组将具有twitter用户名和单个tweet作为逗号分隔值。然后，这个元组的蒸汽将被转发到Bolt，并且Bolt将tweet拆分成单个字，计算字数，并将信息保存到配置的数据源。现在，我们可以通过查询数据源轻松获得结果。

拓扑

Spouts和Bolts连接在一起，形成拓扑结构。实时应用程序逻辑在Storm拓扑中指定。简单地说，拓扑是有向图，其中顶点是计算，边缘是数据流。

简单拓扑从spouts开始。Spouts将数据发射到一个或多个Bolts。Bolt表示拓扑中具有最小处理逻辑的节点，并且Bolts的输出可以发射到另一个Bolts作为输入。

Storm保持拓扑始终运行，直到您终止拓扑。Apache Storm的主要工作是运行拓扑，并在给定时间运行任意数量的拓扑。

任务

现在你有一个关于Spouts和Bolts的基本想法。它们是拓扑的最小逻辑单元，并且使用单个Spout和Bolt阵列构建拓扑。应以特定顺序正确执行它们，以使拓扑成功运行。Storm执行的每个Spout和Bolt称为“任务”。简单来说，任务是Spouts或Bolts的执行。在给定时间，每个Spout和Bolt可以具有在多个单独的螺纹中运行的多个实例。

进程

拓扑在多个工作节点上以分布式方式运行。Storm将所有工作节点上的任务均匀分布。工作节点的角色是监听作业，并在新作业到达时启动或停止进程。

流分组

数据流从Spouts流到Bolts，或从一个Bolts流到另一个Bolts。流分组控制元组在拓扑中的路由方式，并帮助我们了解拓扑中的元组流。有四个内置分组，如下所述。

随机分组

在随机分组中，相等数量的元组随机分布在执行Bolts的所有工人中。下图描述了结构。

字段分组

元组中具有相同值的字段组合在一起，其余的元组保存在外部。然后，具有相同字段值的元组被向前发送到执行Bolts的同一进程。例如，如果流由字段“字”分组，则具有相同字符串“Hello”的元组将移动到相同的工作者。下图显示了字段分组的工作原理。

全局分组

所有流可以分组并向前到一个Bolts。此分组将源的所有实例生成的元组发送到单个目标实例（具体来说，选择具有最低ID的工作程序）。

所有分组

所有分组将每个元组的单个副本发送到接收Bolts的所有实例。这种分组用于向Bolts发送信号。所有分组对于连接操作都很有用。

Apache Storm集群架构

Apache Storm的主要亮点是，它是一个容错，快速，没有“单点故障”（SPOF）分布式应用程序。我们可以根据需要在多个系统中安装Apache Storm，以增加应用程序的容量。

让我们看看Apache Storm集群如何设计和其内部架构。下图描述了集群设计。

Apache Storm有两种类型的节点，Nimbus（主节点）和Supervisor（工作节点）。Nimbus是Apache Storm的核心组件。Nimbus的主要工作是运行Storm拓扑。Nimbus分析拓扑并收集要执行的任务。然后，它将任务分配给可用的supervisor。

Supervisor将有一个或多个工作进程。Supervisor将任务委派给工作进程。工作进程将根据需要产生尽可能多的执行器并运行任务。Apache Storm使用内部分布式消息传递系统来进行Nimbus和管理程序之间的通信。

组件	描述
Nimbus（主节点）	Nimbus是Storm集群的主节点。集群中的所有其他节点称为工作节点。主节点负责在所有工作节点之间分发数据，向工作节点分配任务和监视故障。
Supervisor（工作节点）	遵循指令的节点被称为Supervisors。Supervisor有多个工作进程，它管理工作进程以完成由nimbus分配的任务。
Worker process（工作进程）	工作进程将执行与特定拓扑相关的任务。工作进程不会自己运行任务，而是创建执行器并要求他们执行特定的任务。工作进程将有多个执行器。
Executor（执行者）	执行器只是工作进程产生的单个线程。执行器运行一个或多个任务，但仅用于特定的spout或bolt。
Task（任务）	任务执行实际的数据处理。所以，它是一个spout或bolt。
ZooKeeper framework（ZooKeeper框架）	Apache的ZooKeeper的是使用群集（节点组）自己和维护具有强大的同步技术共享数据之间进行协调的服务。Nimbus是无状态的，所以它依赖于ZooKeeper来监视工作节点的状态。 ZooKeeper的帮助supervisor与nimbus交互。它负责维持nimbus，supervisor的状态。

Storm是无状态的。即使无状态性质有它自己的缺点，它实际上帮助Storm以最好的可能和最快的方式处理实时数据。

Storm虽然不是完全无状态的。它将其状态存储在Apache ZooKeeper中。由于状态在Apache ZooKeeper中可用，故障的网络可以重新启动，并从它离开的地方工作。通常，像monit这样的服务监视工具将监视Nimbus，并在出现任何故障时重新启动它。

Apache Storm还有一个称为Trident拓扑的高级拓扑，它具有状态维护，并且还提供了一个高级API，如Pig。我们将在接下来的章节中讨论所有这些功能。

Apache Storm工作流程 

一个工作的Storm集群应该有一个Nimbus和一个或多个supervisors。另一个重要的节点是Apache ZooKeeper，它将用于nimbus和supervisors之间的协调。

现在让我们仔细看看Apache Storm的工作流程 ?

• 最初，nimbus将等待“Storm拓扑”提交给它。

• 一旦提交拓扑，它将处理拓扑并收集要执行的所有任务和任务将被执行的顺序。

• 然后，nimbus将任务均匀分配给所有可用的supervisors。

• 在特定的时间间隔，所有supervisor将向nimbus发送心跳以通知它们仍然运行着。

• 当supervisor终止并且不向心跳发送心跳时，则nimbus将任务分配给另一个supervisor。

• 当nimbus本身终止时，supervisor将在没有任何问题的情况下对已经分配的任务进行工作。

• 一旦所有的任务都完成后，supervisor将等待新的任务进去。

• 同时，终止nimbus将由服务监控工具自动重新启动。

• 重新启动的网络将从停止的地方继续。同样，终止supervisor也可以自动重新启动。由于网络管理程序和supervisor都可以自动重新启动，并且两者将像以前一样继续，因此Storm保证至少处理所有任务一次。

• 一旦处理了所有拓扑，则网络管理器等待新的拓扑到达，并且类似地，管理器等待新的任务。

默认情况下，Storm集群中有两种模式：

• 本地模式 -此模式用于开发，测试和调试，因为它是查看所有拓扑组件协同工作的最简单方法。在这种模式下，我们可以调整参数，使我们能够看到我们的拓扑如何在不同的Storm配置环境中运行。在本地模式下，storm拓扑在本地机器上在单个JVM中运行。

• 生产模式 -在这种模式下，我们将拓扑提交到工作Storm集群，该集群由许多进程组成，通常运行在不同的机器上。如在storm的工作流中所讨论的，工作集群将无限地运行，直到它被关闭。

Apache Storm分布式消息系统

Apache Storm处理实时数据，并且输入通常来自消息排队系统。外部分布式消息系统将提供实时计算所需的输入。Spout将从消息系统读取数据，并将其转换为元组并输入到Apache Storm中。有趣的是，Apache Storm在内部使用其自己的分布式消息传递系统，用于其nimbus和主管之间的通信。

什么是分布式消息系统？

分布式消息传递基于可靠消息队列的概念。消息在客户端应用程序和消息系统之间异步排队。分布式消息传递系统提供可靠性，可扩展性和持久性的好处。

大多数消息模式遵循发布 - 订阅模型（简称发布 - 订阅），其中消息的发送者称为发布者，而想要接收消息的那些被称为订阅者。

一旦消息已经被发??送者发布，订阅者可以在过滤选项的帮助下接收所选择的消息。通常我们有两种类型的过滤，一种是基于主题的过滤，另一种是基于内容的过滤。

需要注意的是，pub-sub模型只能通过消息进行通信。它是一个非常松散耦合的架构;甚至发件人不知道他们的订阅者是谁。许多消息模式使消息代理能够交换发布消息以便由许多订户及时访问。一个现实生活的例子是Dish电视，它发布不同的渠道，如运动，电影，音乐等，任何人都可以订阅自己的频道集，并获得他们订阅的频道时可用。

下表描述了一些流行的高吞吐量消息传递系统 -

分布式消息系统	描述
Apache Kafka	Kafka是在LinkedIn公司开发的，后来它成为Apache的一个子项目。 Apache Kafka基于brokerenabled的，持久的，分布式的发布订阅模型。 Kafka是快速，可扩展和高效的。
RabbitMQ	RabbitMQ是一个开源的分布式鲁棒消息应用程序。它易于使用并在所有平台上运行。
JMS(Java Message Service)	JMS是一个开源API，支持创建，读取和从一个应用程序向另一个应用程序发送消息。它提供有保证的消息传递并遵循发布 - 订阅模型。
ActiveMQ	ActiveMQ消息系统是JMS的开源API。
ZeroMQ	ZeroMQ是无代理的对等体消息处理。它提供推拉，路由器 - 经销商消息模式。
Kestrel	Kestrel是一个快速，可靠，简单的分布式消息队列。

 

Thrift协议

Thrift在Facebook上构建，用于跨语言服务开发和远程过程调用（RPC）。后来，它成为一个开源的Apache项目。Apache Thrift是一种接口定义语言，允许以容易的方式在定义的数据类型之上定义新的数据类型和服务实现。

Apache Thrift也是一个支持嵌入式系统，移动应用程序，Web应用程序和许多其他编程语言的通信框架。与Apache Thrift相关的一些关键功能是它的模块化，灵活性和高性能。此外，它可以在分布式应用程序中执行流式处理，消息传递和RPC。

Storm广泛使用Thrift协议进行内部通信和数据定义。Storm拓扑只是Thrift Structs。在Apache Storm中运行拓扑的Storm Nimbus是一个Thrift服务。