storm（01）——storm概述及架构模型

Storm是什么？

Storm是twitter公司开源捐献给apache的一个实时流式数据处理的框架。
Storm是一个开源的分布式实时计算系统，可以简单、可靠的处理大量的数据流。
特点在于来一条数据就马上处理一条数据，具有低延迟、高可用、易扩展、数据不丢失等特点。
主要用于解决数据的实时计算以及实时处理的问题。
Storm有很多使用场景：如实时分析，在线机器学习，持续计算，分布式RPC，ETL等等。

Storm的特点

Storm有如下特点：

• 编程模型简单
和hadoop一样，Storm也为大数据的实时计算提供了一些简单优美的原语，大大降低了开发并行实时处理的任务的复杂性，帮助开发者快速、高效的开发应用。

• 可扩展
在Storm集群中真正运行topology的主要有三个实体：工作进程、线程和任务。
Storm集群中的每台机器上都可以运行多个工作进程，每个工作进程又可创建多个线程，每个线程可以执行多个任务，任务是真正进行数据处理的实体，我们开发的spout、bolt就是作为一个或者多个任务的方式执行的。
因此，计算任务在多个线程、进程和服务器之间并行进行，支持灵活的水平扩展。

• 高可靠性
Storm可以保证spout发出的每条消息都能被“完全处理”，这也是直接区别于其他实时系统的地方。
请注意，spout发出的消息后续可能会触发产生成千上万条消息，可以形象的理解为一棵消息树，其中spout发出的消息为树根，Storm会跟踪这棵消息树的处理情况，只有当这棵消息树中的所有消息都被处理了，Storm才会认为spout发出的这个消息已经被“完全处理”。如果这棵消息树中的任何一个消息处理失败了，或者整棵消息树在限定的时间内没有“完全处理”，那么spout发出的消息就会重发。
考虑到尽可能减少对内存的消耗，Storm并不会跟踪消息树中的每个消息，而是采用了一些特殊的策略，它把消息树当作一个整体来跟踪，对消息树中所有消息的唯一id进行异或计算，通过是否为零来判定spout发出的消息是否被“完全处理”，这极大的节约了内存和简化了判定逻辑，后面会对这种机制进行详细介绍。
这种模式，每发送一个消息，都会同步发送一个ack/fail，对于网络的带宽会有一定的消耗，如果对于可靠性要求不高，可通过使用不同的emit接口关闭该模式。
上面所说的，Storm保证了每个消息至少被处理一次，但是对于有些计算场合，会严格要求每个消息只被处理一次，幸而Storm的0.7.0引入了事务性拓扑，解决了这个问题。

• 高容错性
如果在消息处理过程中出了一些异常，Storm会重新安排这个出问题的处理单元。Storm保证一个处理单元永远运行（除非你显式杀掉这个处理单元）。
当然，如果处理单元中存储了中间状态，那么当处理单元重新被Storm启动的时候，需要应用自己处理中间状态的恢复。

• 支持多种编程语言
除了用java实现spout和bolt，你还可以使用任何你熟悉的编程语言来完成这项工作，这一切得益于Storm所谓的多语言协议。多语言协议是Storm内部的一种特殊协议，允许spout或者bolt使用标准输入和标准输出来进行消息传递，传递的消息为单行文本或者是json编码的多行。
Storm支持多语言编程主要是通过ShellBolt, ShellSpout和ShellProcess这些类来实现的，这些类都实现了IBolt 和 ISpout接口，以及让shell通过java的ProcessBuilder类来执行脚本或者程序的协议。
可以看到，采用这种方式，每个tuple在处理的时候都需要进行json的编解码，因此在吞吐量上会有较大影响。

• 支持本地模式
Storm有一种“本地模式”，也就是在进程中模拟一个Storm集群的所有功能，以本地模式运行topology跟在集群上运行topology类似，这对于我们开发和测试来说非常有用。

storm的架构模型

角色说明：
nimbus：storm当中的主节点，负责资源分配和任务调度。主要用于接收客户端提交的topology，以及分配任务的执行，nimbus可以有多个。

zookeeper：维持主节点与从节点的通信，维持一些公共信息，集群的状态监控以及nimbus分配的任务都写入到zk当中来。

supervisor：storm当中的从节点，主要用于接收nimbus分配的任务，并负责管理自己的worker进程。

worker：运行具体的处理逻辑的进程，我们提交的任务，可以指定通过几个进程来进行执行。

executor：线程的概念，执行器，真正执行我们的代码的东西，这个是线程的概念。

task：在新的版本（jstorm）当中已经没有意义了

topology：我们提交的一个任务就是一个topology