Storm学习03--各个角色的功能

Strom的架构

从上图我们可以看到：Strom中有几个主要的角色：
nimbus, zookeeper, supervisor, worker, executor,使得Strom健壮的运行。

二、各个角色的功能

Nimbus

• 集群管理
• 调度topology

supervisor

• 启停Worker

Worker

• 一个JVM进程资源分配的单位
• 启动executor

Executor

• 实际干活的线程

Zookeeper

• 存储状态信息，调度信息， 心跳。

三、Nimubus

  nimbus相当于master, Storm是master/slave的架构。
主要负责两个事情:

• 管理集群： slave都向zookeeper写信息, 然后nimbus从zookeeper中获取这些slave的节点信息，那么nimbus就直到集群中有多少个节点，节点处于什么样的状态，都运行什么样的任务。
• 调度topology：当一个topology通过接口提交到集群上，nimbus负责将里面的Worker分配到supervisor上面执行。

四、Supervisor

  每台机器都会起一个supervisor进程， supervisor就是slave。

• supervisor启停Worker: 当nimbus分配worker之后， supervisor就会启动worker,worker开始工作。

五、Woker

实际干活的是Worker, 每个机器上的supervisor可以启动多个Worker, 每个机器会配置一定数量的Woker(4个)。
一个Worker,就是一个JVM
Worker其实两件事：

• 启动executor:
• worker与worker之间的数据交流：负责同一个topolopy中worker和worker之间 的传输， task的数据传输是通过worker进行的， topology和topology之间没有任何相关性。

六、Executor

真正干活的是Worker里面的executor，Worker启动了Executor，

• 功能：执行Spout， Bolt中的nextTuple(), execute()这些回调函数。

七、Zookeeper

  我们先来看看zookeeper，刚才我们也说过了，zookeeper是nimbus和 supervisor向里面读写一些原数据信息的，具体会写什么信息呢，
存储心跳：会把心跳写上去，具体读取心跳信息的人再去zookeeper上面去读取信息，
调度信息，错误信息：，当task执行错误的时候呢，把错误的信息写到zookeeper上去，这样的话，在webUI上我们就可以读取这些信息，把情况给展示出来
  • 实际上呢，Storm用zookeeper呢，使用的非常简单，它就把它当做一个高可用的KV来使用，storm使用zookeeper呢需求非常简单，就是说让整个集群别变成无状态的，就是任何节点挂了呢，受影响都不大，包括nimbus这种master进程挂掉 的话，整个集群都还是能工作的，它要做到这一点呢就需要把状态信息元数据存储到一个KV里面去，存储到一个系统里面去，最简单的就是一个KV就解决了，之所以选用zookeeper呢，是因为它是一个分布式的，高可用的小KV的一个系统，它里面一般是3个或者5个机器，当它的机器坏掉的数目不超过一半的时候呢，zookeeper还是可用的，所以zookeeper在这里起到了一个高可用的作用，比如说我们一般部署5台机器，在宕掉一台或者两台机器的时候呢，都能正常使用，都没有问题。
  •storm用zookeeper呢，和其它的master/slave的技术使用zookeeper呢还是有点不一样，比如hadoop他是一个典型的master/slave架构，但是在hadoop里面呢，所有的salve都会向master去汇报状态，比如mapreduce里面的tracker都会向 jobtracker汇报，这样呢在jobtracker里面的内存呢就会有所有tracker的状态，同 时在tracker向jobtracker汇报心跳的时候呢，jobtracker会在回应里面呢，带上你 要执行的task，tracker你要执行什么task这样的信息，hadoop这种方式的好处是 比较直接，slave向master汇报心跳，master给slave一些指令，很简单很清晰，storm之所以不采用这种架构是因为这种需要保证更好更高的可用性，因为如果宕机会有延迟，流式计算里面对延迟接受度是比较低的，因为业务如果延迟10分钟 什么的话，影响是很大的，storm就是要保证当任何挂掉的时候，业务可以稳定运 行，所以它需要各个进程都是无状态的。
  • 比如nimbus，如果各个节点都向它汇报，如果nimbus一旦挂了，那就存在这些个状态信息怎么恢复的问题，各个节点连不上的时候，怎么处理的问题，所以storm它的做法是各个节点都把状态信息往zk上写，因为zk我们认为是可靠地，这样比如说如果nimbus挂了，那再新起一个nimbus， 它去zk上面去取Supervisor的信息，它就可以立刻知道supervisor处于一 个什么状态，supervisor也一样，它不需要与nimbus通信，它的心跳是往zk上面写的，而它启动task的时候呢，也不是从nimbus上面要task，而是 nimbus把Task放到zookeeper上面去，然后supervisor再去zk上面去读，然后读到task之后呢再去启动task，所以相互之间通过zk做了一个解耦，zk又是高可用的，非常好的，又是集群的方式，达到了一个非常高的稳定性，这个从架构上来讲的话呢，比hadoop的架构要更先进一些了。

Storm向zookeeper上写什么?