zookeeper leader選舉

     如何在zookeeper集羣中選舉出一個leader,zookeeper使用了三種算法,具體使用哪一種算法,在配置文件中是能夠配置的,對應的配置項是」electionAlg」,其中1對應的是LeaderElection算法,2對應的是AuthFastLeaderElection算法,3對應的是FastLeaderElection算法.默認使用FastLeaderElection算法，此處僅以默認算法流程；
     首先了解幾個屬性：
      electionEpoch：每執行一次leader選舉，electionEpoch就會自增，用來標記leader選舉的輪次
      peerEpoch：每次leader選舉完成以後，都會選舉出一個新的peerEpoch，用來標記事務請求所屬的輪次
      serverID：配置文件中配置的每一個服務器對應的ID
      zxid:爲了保證事務一致性，zk採用了遞增的事務ID號（zxid）來標識事務。全部的提議都在唄提出的時候加上了zxid。實現中，zxid是一個64位的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的peerEpoch，標識當前屬於那個leader的通知時期，低32位用於遞增計數；
     選舉狀態：
          Looking: 當前server不知道leader是誰，正在搜尋
          Following:leader已經選舉出來，當前server與之同步
          Leading:當前server即爲選舉出來的leader
          Observing:大多數行爲與following一致，可是不參加選舉，只接受選舉的結果

   選舉發送內容：
     serverID，zxid,peerEpoch，當前選舉狀態；

   選舉流程：
     1.每一個服務器都發送本身選舉的leader，首輪會發送的選票都會投給本身；
     2.服務器收到其餘服務器的選票：
      收到的推薦人是looking狀態：
       首先判斷邏輯時間：
         (1) 收到的選票邏輯時間大於目前的邏輯時鐘，則說明選舉已經進入新一輪了，因此須要更新本機邏輯時間，並清空以前收到的選票信息；而後更新選票信息，廣播出去；
         (2) 收到的選票邏輯時間等於目前的邏輯時鐘，則判斷是否須要更新推薦人，如更新，則廣播出去； 
       而後記錄選票信息，本地進行選舉，如選舉出來，則等待一段時間沒有新的選票後，則進行角色確認，更改狀態返回最終選票；
      收到的推薦人是following、leading狀態：
       (1)  收到的選票邏輯時間等於目前的邏輯時鐘，進行本地選舉，並肯定收到的選票爲leader，若是肯定，則進行角色確認，返回最終選票
       (2)  若是上一步沒有肯定角色且返回最終選票，則將選票存入outofelection中，進行再次選舉，若是能肯定出leader，且肯定收到的選票爲leader，若是肯定，則進行角色確認，返回最終選票；
  流程圖：
       
  選舉斷定：
       依次斷定peerEpoch,zxid,serverId
        
   
    
 選舉源碼類：
      FastLeaderElection,實現Election接口的lookForLeader方法，從類關係上來看，AuthFastLeaderElection，LeaderElection這兩個實現類已經被廢棄，目前僅剩FastLeaderElection這個實現類；
      

 以上爲最近根據源碼及網上資料總結，總結的過程當中可使本身的理解更深入，
 

 
   參考資料： 
    http://codemacro.com/2014/10/19/zk-fastleaderelection/ 
    http://http://www.cnblogs.com/leesf456/p/6508185.html 
    http://blog.jobbole.com/107583/