ZooKeeper是以Fast Paxos算法爲基礎的，Paxos 算法存在活鎖的問題，即當有多個proposer交錯提交時，有可能互相排斥導致沒有一個proposer能提交成功，而Fast Paxos作了一些優化，通過選舉產生一個leader (領導者)，只有leader才能提交proposer，具體算法可見Fast Paxos。因此，要想弄懂ZooKeeper首先得對Fast Paxos有所瞭解。
ZooKeeper的基本運轉流程：
1、選舉Leader。
2、同步數據。
3、選舉Leader過程中算法有很多，但要達到的選舉標準是一致的。
4、Leader要具有最高的zxid。
5、集羣中大多數的機器得到響應並follow選出的Leader
zoo.cfg
#客戶端連接server的端口，即對外服務端口，一般設置爲2181
clientPort=2183
#在運行過程中，Leader負責與ZK集羣中所有機器進行通信，例如通過一些心跳檢測機制，來檢測機器的存活狀態。如果L發出心跳包在syncLimit之後，還沒有從F那裏收到響應，那麼就認爲這個F已經不在線了
syncLimit=5
#ZK提供了自動清理事務日誌和快照文件的功能，這個參數指定了清理頻率，單位是小時，需要配置一個1或更大的整數，默認是0，表示不開啓自動清理功能。
autopurge.purgeInterval=1
#單個客戶端與單臺服務器之間的連接數的限制，是ip級別的，默認是60，如果設置爲0，那麼表明不作任何限制。請注意這個限制的使用範圍，僅僅是單臺客戶端機器與單臺ZK服務器之間的連接數限制，不是針對指定客戶端IP，也不是ZK集羣的連接數限制，也不是單臺ZK對所有客戶端的連接數限制
maxClientCnxns=0
#存儲快照文件snapshot的目錄。默認情況下，事務日誌也會存儲在這裏。建議同時配置參數dataLogDir, 事務日誌的寫性能直接影響zk性能。
dataDir=/usr/local/...
#Follower在啓動過程中，會從Leader同步所有最新數據，然後確定自己能夠對外服務的起始狀態。Leader允許F在 initLimit 時間內完成這個工作。通常情況下，我們不用太在意這個參數的設置。如果ZK集羣的數據量確實很大了，F在啓動的時候，從Leader上同步數據的時間也會相應變長，因此在這種情況下，有必要適當調大這個參數了。
initLimit=10
#這個參數指定了需要保留的文件數目。默認是保留3個
autopurge.snapRetainCount=30
#這裏的x是一個數字，與myid文件中的id是一致的。右邊可以配置兩個端口，第一個端口用於F和L之間的數據同步和其它通信，第二個端口用於Leader選舉過程中投票通信。
server.x=master:2898:3898
#ZK中的一個時間單元。ZK中所有時間都是以這個時間單元爲基礎，進行整數倍配置的。例如，session的最小超時時間是2*tickTime。
tickTime=3000
需要注意的是：dataDir目錄下數據文件 myid 文件中的數值在集羣zookeeper的配置中是唯一的