Storm在1.0之后对nimbus支持了HA，根据官方提供的文档，同样是利用了zk来做分布式锁，并且配置文件中新增了storm.seeds，而原来的storm.hosts改为deprecated。但是nimbus如果想成为leader，必须有一个先决条件就是这个nimbus本地必须包含所有的topo的代码（code），否则这个nimbus是不会接受leader角色的。
首先看启动，nimbus的启动通过命令行的方式./storm nimbus，在启动脚本中又调用storm.py的脚本，而这个python脚本则直接指向了
o.a.s.d.nimbus
、
在初始化的过程中，首先实现了INimbus的接口
接下来，-lauch方法对配置文件做了解析，然后实际启动server是launch-server方法
launch-server方法做了如下几件事情
1. 验证是否为本地模式，如果是local模式则抛异常
2. 验证端口是否可用，就是配置文件中的thrift.server的端口
3. 注意service-handler这个方法，在它的内部其实做了很多事情
接下来看看service-handler这个方法，service-handler定义了一系列的方法，这些方法都是用于提供对外服务。
首先service-handler通过let绑定了nimbus (nimbus-data conf inimbus), nimbus-data其实提供了许多运行时需要的nimbus数据。
这里只谈HA，在nimbus-data中有这样一对键值对
而zk-leader-elector利用了zk的leader-latch做leader选举
nimbus.clj下的这一段是定时从其他nimbus同步代码的核心
在这里，blob-sync做了在不同nimbus上同步sync。这里的注释写的很明白，定期去同步其他nimbus的code。blob-sync是个多态方法。首先看看下面这个逻辑
1. 判断是不是leader，如果不是leader，转到2（是leader就有全部的code了，自然不需要做其他事情）
2. 构建一个BlobSyncronizer对象，执行syncBlobs方法
blob-sync方法中通过let绑定的值有几个，这里可以看一下相对比较复杂的zk-key-set，这个zk-key-set绑定了一个set的数据结构，
而这个set的数据结构的值又是来源于storm-cluster-stat的blobstore方法。那么现在就看看storm-cluster-state方法是怎么来的。
可以看到通过追溯代码，能够发现其来源于nimbus-data的一个绑定，这个绑定中的一个方法就是mk-storm-cluster-state.
那么mk-storm-cluster-state这个方法有做了什么呢？
让我们进入定义它的cluster.clj去看一下。
这里详细解释了cluster-state的来源，其实它是通过mk-distributed-cluster-state方法创建出来的一个对象，而这个对象就是通过反射得到的org.apache.storm.cluster_state.zookeeper_state_factory这样一个对象
弄清楚cluster-state的来源，我们回头再看zk-key-set的blobstore方法
这个方法其实就是调用了org.apache.storm.cluster_state.zookeeper_state_factory的几个方法。至于sync_path和get_chmk的逻辑就不再赘述了。
blob-sync方法在做完绑定之后，执行了syncBlobs方法，这个方法定义在BlobSyncronizer中。首先这个方法利用synchronized表明这是个同步方法。这个方法中
1. 删除不在zk上，而在blobstore中的key
2. updateKeySetForBlobStore，这个方法里检查了zk上所有的最近一个version的blobstore，并且检查当前的nimbus是否含有这个最近版本的key。如果没有，那么则在zk上创建一个。而创建的方法则是通过thrift接口调用createStateInZookeeper实现的
3. 既然zk上的路径也创建了，那么接下来就应该创建本地文件了（如何下载的没有深究，好像是用到了bt协议？）
这样就完成了HA的分析，总结一下：
通过定时任务，定时去检查是否有未下载的blob，如果有则下去下载。另外通过zk的leader-latch做选举，
如果被选为leader，那么需要检查是否有足够多的key，如果没有则放弃。
