Hadoop与Storm都是典型的主从架构，但是在使用 Zookeeper时还是不太一样的。 一、对于Hadoop来说，所有的 slaves都需要向master汇报状态信息，比如：MapReduce里的Tasktracker会向Jobtracker汇报，从而，Jobtracker所在节点内存中会有Tasktracker的状态信息，同时TaskTracker会收到JobTracker的响应信息，告诉TaskTracker需要做的任务。这种方式的优点是：直接、清晰，slave直接向master汇报状态，master返回给slave相关任务。但缺点是：因为这种“状态”进程的恢复是需要时间的，即有很大的延迟，而这种延迟在流式计算中的接受度是很低的，所以，Storm并没有采取这种模式。 二、对于Storm来说，它的主（nimbus），从（supervisor）。 首先，所有的supervisor会将自己的节点信息写至Zookeeper，之后nimbus会从Zookeeper上获取到supervisor的信息，再将topology里的workers按照负载均衡的思想分配至supervisor中，不过这个过程也是写入zookeeper中，而不是直接发送给supervisor，supervisor再从zookeeper上获取任务信息。再去调度Executors去执行。 从而，zookeeper对Storm来说就相当于一个高可用的kv,把节点的状态信息元数据都存入一个kv里，从而使得各个节点都是“无状态”的，那么任何节点崩溃后，都不存在“状态恢复的问题”。直接去zookeeper上拿就行了。比如：nimbus挂了，重启一个nimbus,直接去zookeeper上获取supervisor的信息即可，可以立即知道supervisor所处状态。supervisor挂了，不需要与nimbus通信，它的心跳 是写在zookeeper中的，启动Task也是直接从zookeeper上去（nimbus之前写进去的）。 所以，zookeeper相当于对nimbus与supervisor之间做了一个解耦，所以这种应用就比Hadoop的应用更先进。 唯一的问题是：当nimbus挂了的时候，无法将出错了的supervisor中的任务重新分配到其他supervisor
