1 集群架构
1.1 Nimbus
Nimbus是整个集群的调度器，负责分发Topology到各个Supervisor、分配Task、监控Supervisor以及Topology，并且通过ZK与Supervisor交互。
1.2 Supervisor
任务执行者，通过ZK接收Nimbus指令，负责接收任务、执行任务。
2 基本概念
2.1 Stream
JStorm包含抽象的概念流，流是一个连续的无界Tuple序列。注意，在JStorm中建模事件流时，Stream中的抽象事件是Tuple。
2.2 Topology
上图是一个有向无环图，在JStorm中这张图被抽象为一个Topology（拓扑），Topology是JStorm中最高级别的抽象，可以提交给JStorm集群运行。拓扑结构是一个数据流转换图，上面图中的每个节点表示一个Spout（水龙头）或Bolt（螺栓），图中的每个边表示一个数据流。在Spout或Bolt向流发送Tuple之后，它将向从该流订阅的每个Bolt发送Tuple（这意味着流将主动地被发送到订阅了该流的所有Bolt）。JStorm中Topology是如何实现的呢，为了实时计算，我们需要设计一个Topology并实现Bolt的处理细节，这样我们就可以使用程序来创建或提交拓扑。
2.3 Spout/Bolt
Spout和Bolt是Storm为流转换提供的两个基本概念，我们在程序中需要继承相关接口实现自己的Spout或Bolt。
JStorm认为每个流都有一个源，因此源被抽象为Spout（水龙头）。Spout可以连接到消息传递中间件组件（metaq、kafka、activemq、tbnotify等）并连续发送消息，也可以连续地从队列中读取消息，并通过队列元素组装成元组发出。
一个Bolt可以消耗任意数量的输入流，进行一些处理，并可能发出新的流。复杂的流转换，可能需要多个步骤，因此需要多个Bolt。Bolt可以做任何事情，从运行函数，过滤元组，流聚合，流连接，操作数据库等等。
Spout和Bolt网络被打包成一个Topology，并提交给Storm集群进行执行。Topology是 一个流变换图，其中每个节点都是一个Spout或Bolt。图中的边指示哪些Bolt订阅哪些流。这样可以再一次理解为什么当Spout或Bolt向流发送元组时，它会将元组发送到订阅该流的每个Bolt。
2.4 Tuple
流中的数据在JStorm中被抽象为Tuple（元组）。Tuple是一个值列表，列表中的每个值都有一个名称，值可以是基本类型、字符类型、字节数组，当然，也可以是任何其他可序列化类型。Topology中每个节点发出的Tuple必须有一个名称，其他节点只需订阅该名称。
2.5 Worker
总的进程数，表示有多少个进程在执行topology。
2.6 Task
每个worker代表一个进程，一个worker中可以有一个或多个task，代表一个执行线程，每个task都是组件（spout或bolt）的实现。每个spout和bolt都可以单独指定一个并行度（parallelism），代表同时有多少个线程（task）来执行这个spout或bolt。（有的文档中还介绍了executor的概念，认为executor代表线程数，task是excecutor中执行的任务，但官网中并没有介绍excecutor，这里先存疑）
JStorm中，每一个执行线程都有一个task id，它从1开始递增，每一个组件中的task id是连续的。
JStorm有均匀调度算法，保证每个worker中执行的task数一致，但task可能由不同类型、数量的组件构成。比如一个worker中的有5个task，则可能是1个spout+4个bolt，或2个spout+3个bolt。
http://120.25.204.125/QuickStart/BasicConception.html
