Storm在1.0之后對nimbus支持了HA猖任，根據(jù)官方提供的文檔尺上，同樣是利用了zk來做分布式鎖金顿，并且配置文件中新增了storm.seeds，而原來的storm.hosts改為deprecated贰您。但是nimbus如果想成為leader坏平，必須有一個先決條件就是這個nimbus本地必須包含所有的topo的代碼（code），否則這個nimbus是不會接受leader角色的锦亦。
首先看啟動舶替，nimbus的啟動通過命令行的方式./storm nimbus，在啟動腳本中又調(diào)用storm.py的腳本杠园，而這個python腳本則直接指向了
o.a.s.d.nimbus
坎穿、
在初始化的過程中，首先實現(xiàn)了INimbus的接口
接下來返劲，-lauch方法對配置文件做了解析玲昧，然后實際啟動server是launch-server方法
launch-server方法做了如下幾件事情
1. 驗證是否為本地模式，如果是local模式則拋異常
2. 驗證端口是否可用篮绿，就是配置文件中的thrift.server的端口
3. 注意service-handler這個方法孵延，在它的內(nèi)部其實做了很多事情
接下來看看service-handler這個方法，service-handler定義了一系列的方法亲配，這些方法都是用于提供對外服務(wù)尘应。
首先service-handler通過let綁定了nimbus (nimbus-data conf inimbus), nimbus-data其實提供了許多運行時需要的nimbus數(shù)據(jù)。
這里只談HA吼虎，在nimbus-data中有這樣一對鍵值對
而zk-leader-elector利用了zk的leader-latch做leader選舉
nimbus.clj下的這一段是定時從其他nimbus同步代碼的核心
在這里犬钢，blob-sync做了在不同nimbus上同步sync。這里的注釋寫的很明白思灰，定期去同步其他nimbus的code玷犹。blob-sync是個多態(tài)方法。首先看看下面這個邏輯
1. 判斷是不是leader洒疚，如果不是leader歹颓，轉(zhuǎn)到2（是leader就有全部的code了，自然不需要做其他事情）
2. 構(gòu)建一個BlobSyncronizer對象油湖，執(zhí)行syncBlobs方法
blob-sync方法中通過let綁定的值有幾個巍扛，這里可以看一下相對比較復(fù)雜的zk-key-set，這個zk-key-set綁定了一個set的數(shù)據(jù)結(jié)構(gòu)乏德，
而這個set的數(shù)據(jù)結(jié)構(gòu)的值又是來源于storm-cluster-stat的blobstore方法撤奸。那么現(xiàn)在就看看storm-cluster-state方法是怎么來的。
可以看到通過追溯代碼喊括，能夠發(fā)現(xiàn)其來源于nimbus-data的一個綁定胧瓜，這個綁定中的一個方法就是mk-storm-cluster-state.
那么mk-storm-cluster-state這個方法有做了什么呢？
讓我們進入定義它的cluster.clj去看一下瘾晃。
這里詳細解釋了cluster-state的來源贷痪，其實它是通過mk-distributed-cluster-state方法創(chuàng)建出來的一個對象，而這個對象就是通過反射得到的org.apache.storm.cluster_state.zookeeper_state_factory這樣一個對象
弄清楚cluster-state的來源蹦误，我們回頭再看zk-key-set的blobstore方法
這個方法其實就是調(diào)用了org.apache.storm.cluster_state.zookeeper_state_factory的幾個方法劫拢。至于sync_path和get_chmk的邏輯就不再贅述了。
blob-sync方法在做完綁定之后强胰，執(zhí)行了syncBlobs方法舱沧，這個方法定義在BlobSyncronizer中。首先這個方法利用synchronized表明這是個同步方法偶洋。這個方法中
1. ?刪除不在zk上熟吏，而在blobstore中的key
2. updateKeySetForBlobStore，這個方法里檢查了zk上所有的最近一個version的blobstore，并且檢查當前的nimbus是否含有這個最近版本的key牵寺。如果沒有悍引，那么則在zk上創(chuàng)建一個。而創(chuàng)建的方法則是通過thrift接口調(diào)用createStateInZookeeper實現(xiàn)的
3. 既然zk上的路徑也創(chuàng)建了帽氓，那么接下來就應(yīng)該創(chuàng)建本地文件了（如何下載的沒有深究趣斤，好像是用到了bt協(xié)議？）
這樣就完成了HA的分析黎休，總結(jié)一下：
通過定時任務(wù)浓领，定時去檢查是否有未下載的blob，如果有則下去下載势腮。另外通過zk的leader-latch做選舉联贩，
如果被選為leader，那么需要檢查是否有足夠多的key捎拯，如果沒有則放棄泪幌。
