[TOC] # Zookeeper簡介 ## 1 概念介紹 > Zookeeper是一個分布式協調服務；就是為用戶的分布式應用程序提供協調服務 1. zookeeper是為別的分布式程序服務的 2. Zookeeper本身就是一個分布式程序（只要有半數以上節點存活，zk就能正常服務） 3. Zookeeper所提供的服務涵蓋：主從協調、服務器節點動態上下線、統一配置管理、分布式共享鎖、統一名稱服務…… 4. 雖然說可以提供各種服務，但是zookeeper在底層其實只提供了兩個功能： * 管理(存儲，讀取)用戶程序提交的數據； * 并為用戶程序提供數據節點監聽服務； ## 2 常用應用場景 > 主從協調  > 配置管理  ## 3 Zookeeper 集群部署 ### 1、Zookeeper集群角色 > Zookeeper集群的角色： Leader 和 follower （Observer） > zk集群最好配成奇數個節點 > 只要集群中有半數以上節點存活，集群就能提供服務 ### 2 Zookeeper部署 #### 2.1 機器準備 > 1/ 安裝到3臺虛擬機上 > 2/ 安裝好JDK > 3/ 上傳安裝包。上傳用工具。 > 4/ 解壓 ~~~ su - hadoop（切換到hadoop用戶） tar -zxvf zookeeper-3.4.5.tar.gz（解壓） ~~~ > 5/ 重命名 > mv zookeeper-3.4.5 zookeeper（重命名文件夾zookeeper-3.4.5為zookeeper） > 可以刪除里面一些源碼工程相關的文件，剩下的是這些： #### 2.2修改環境變量 > （注意：3臺zookeeper都需要修改） > 1/ su – root(切換用戶到root) > 2/ vi /etc/profile(修改文件) > 3/ 添加內容： ~~~ export ZOOKEEPER_HOME=/home/hadoop/zookeeper export PATH=$PATH:$ZOOKEEPER_HOME/bin ~~~ > 4/ 加載環境配置： ~~~ source /etc/profile ~~~ > 5/ 修改完成后切換回hadoop用戶： ~~~ su - hadoop ~~~ #### 2.3 修改Zookeeper配置文件 > 1、用root用戶操作 ~~~ cd zookeeper/conf cp zoo_sample.cfg zoo.cfg ~~~ > 2、vi zoo.cfg > 3、添加內容： ~~~ dataDir=/root/apps/zookeeper/zkdata dataLogDir=/home/hadoop/zookeeper/log server.1=mini1:2888:3888 ## (心跳端口、選舉端口) server.2=mini2:2888:3888 server.3=mini3:2888:3888 ~~~ > 4、創建文件夾： ~~~ cd /home/hadoop/zookeeper/ mkdir zkdata mkdir -m 755 log ~~~ > 5、在data文件夾下新建myid文件，myid的文件內容為： ~~~ cd zkdata echo 1 > myid ~~~ #### 2.4 分發安裝包到其他機器 ~~~ scp -r /root/apps root@mini2:/root/ scp -r /root/apps root@mini3:/root/ ~~~ #### 2.5 修改其他機器的配置文件 ~~~ 到mini2上：修改myid為：2 到mini3上：修改myid為：3 ~~~ #### 2.6 啟動（每臺機器） > 注： > 1、事先將三臺服務器的防火墻都關掉 > 2、全網統一hosts映射 > 先配好一臺上的hosts > 然后： ~~~ scp /etc/hosts mini2:/etc scp /etc/hosts mini3:/etc ~~~ > 3、然后一臺一臺地啟動 ~~~ bin/zkServer.sh start ~~~ ~~~ 或者編寫一個腳本來批量啟動所有機器： for host in "mini1 mini2 mini3" do ssh $host "source/etc/profile;/root/apps/zookeeper/bin/zkServer.sh start" ~~~ #### 2.7 查看集群狀態 ~~~ 1、jps（查看進程） 2、zkServer.sh status（查看集群狀態，主從信息） ~~~ ## 4 Zookeeper核心工作機制 ### 1 zookeeper特性 1. Zookeeper：一個leader，多個follower組成的集群 2. 全局數據一致：每個server保存一份相同的數據副本，client無論連接到哪個server，數據都是一致的 3. 分布式讀寫，更新請求轉發，由leader實施 4. 更新請求順序進行，來自同一個client的更新請求按其發送順序依次執行 5. 數據更新原子性，一次數據更新要么成功（半數以上節點成功），要么失敗 6. 實時性，在一定時間范圍內，client能讀到最新數據 ### 2 zookeeper數據結構 #### 2.1 概況 1. 層次化的目錄結構，命名符合常規文件系統規范(見下圖) 2. 每個節點在zookeeper中叫做znode,并且其有一個唯一的路徑標識 3. 節點Znode可以包含數據(只能存儲很小量的數據，<1M;最好是1k字節以內)和子節點（但是EPHEMERAL類型的節點不能有子節點，下一頁詳細講解） 4. 客戶端應用可以在節點上設置監視器（后續詳細講解） #### 2.2 數據結構圖  wps1A0D #### 2.3 節點類型 > 1、Znode有兩種類型： ~~~ 短暫（ephemeral）（斷開連接自己刪除） 持久（persistent）（斷開連接不刪除） ~~~ > 2、Znode有四種形式的目錄節點（默認是persistent ） ~~~ PERSISTENT PERSISTENT_SEQUENTIAL（持久序列/test0000000019 ） EPHEMERAL EPHEMERAL_SEQUENTIAL ~~~ > 3、創建znode時設置順序標識，znode名稱后會附加一個值，順序號是一個單調遞增的計數器，由父節點維護 > 4、在分布式系統中，順序號可以被用于為所有的事件進行全局排序，這樣客戶端可以通過順序號推斷事件的順序 ## 5 原理補充 > Zookeeper雖然在配置文件中并沒有指定master和slave > 但是，zookeeper工作時，是有一個節點為leader，其他則為follower > Leader是通過內部的選舉機制臨時產生的 ### 1 zookeeper的選舉機制（zk的數據一致性核心算法paxos） > 以一個簡單的例子來說明整個選舉的過程. > 假設有五臺服務器組成的zookeeper集群,它們的id從1-5,同時它們都是最新啟動的,也就是沒有歷史數據,在存放數據量這一點上,都是一樣的.假設這些服務器依序啟動,來看看會發生什么. 1) 服務器1啟動,此時只有它一臺服務器啟動了,它發出去的報沒有任何響應,所以它的選舉狀態一直是LOOKING狀態 2) 服務器2啟動,它與最開始啟動的服務器1進行通信,互相交換自己的選舉結果,由于兩者都沒有歷史數據,所以id值較大的服務器2勝出,但是由于沒有達到超過半數以上的服務器都同意選舉它(這個例子中的半數以上是3),所以服務器1,2還是繼續保持LOOKING狀態. 3) 服務器3啟動,根據前面的理論分析,服務器3成為服務器1,2,3中的老大,而與上面不同的是,此時有三臺服務器選舉了它,所以它成為了這次選舉的leader. 4) 服務器4啟動,根據前面的分析,理論上服務器4應該是服務器1,2,3,4中最大的,但是由于前面已經有半數以上的服務器選舉了服務器3,所以它只能接收當小弟的命了. 5) 服務器5啟動,同4一樣,當小弟. ### 9.2 非全新集群的選舉機制(數據恢復) > 那么，初始化的時候，是按照上述的說明進行選舉的，但是當zookeeper運行了一段時間之后，有機器down掉，重新選舉時，選舉過程就相對復雜了。 > 需要加入數據version、leader id和邏輯時鐘。 > 數據version：數據新的version就大，數據每次更新都會更新version。 > Leader id：就是我們配置的myid中的值，每個機器一個。 > 邏輯時鐘：這個值從0開始遞增,每次選舉對應一個值,也就是說: 如果在同一次選舉中,那么這個值應該是一致的 ; 邏輯時鐘值越大,說明這一次選舉leader的進程更新. > 選舉的標準就變成： 1. 邏輯時鐘小的選舉結果被忽略，重新投票 2. 統一邏輯時鐘后，數據id大的勝出 3. 數據id相同的情況下，leader id大的勝出 > 根據這個規則選出leader。