1.Zookeeper是分散式應用程式的協調服務框架，是Hadoop的重要元件。 ZK要解決的問題： a.分散式環境下的資料一致性。 b.分散式環境下的統一命名服務 c.分散式環境下的配置管理 d.分散式環境下的分散式鎖   單臺機器使用的鎖：同步程式碼塊、重入鎖。但是在分散式環境這個鎖就發揮不出來作用。共享鎖(常用於資料庫中的讀操作)和排他鎖(寫操作) e.叢集管理問題 分散式的思想：就是人多幹活快，即用多臺機器同時處理一個任務。 2.分散式程式設計容易出現的問題   a.活鎖定義：在程式裡，由於某些條件的發生碰撞，導致重新執行，再碰撞=》再執 行，如此迴圈往復，就形成了活鎖。活鎖的危害：多個執行緒爭用一個資源，但是沒有任何一個執行緒能拿到這個資源。(通俗理解為兩人過樓道，互相謙讓)   b.死鎖定義：死鎖是有一個執行緒拿到資源，但相互等待互不釋放造成死鎖。   活鎖 是死鎖的變種。補充：活鎖更深層次的危害，很耗盡Cpu資源（在做無意義的排程）   c.需要考慮叢集的管理問題，需要有一套機制來檢測到叢集裡節點的狀態變化。（可以用心跳 機制來做，但zk不是用心跳機制來做的）   d.如果用一臺機器做叢集管理，存在單點故障問題，所以針對叢集管理，也需要形成一個叢集 3.ZK指令   a.create建立節點指令，注意，在建立節點時，要分配初始資料。 如：create /zk01 ''  create /zk02 'hello zookeeper'   b.get檢視節點資料指令。 如： get /zk01   get檢視節點資料指令   hello  資料   cZxid = 0x2   ctime = Mon May 15 05:58:32 PDT 2017建立節點的時間戳   mZxid = 0x2   mtime = Mon May 15 05:58:32 PDT 2017修改此節點資料的最新時間戳   pZxid = 0x2   cversion = 0   dataVersion = 0資料版本號，每當資料發生編號，版本號遞增1   aclVersion = 0   ephemeralOwner = 0x0   dataLength = 5資料大小   numChildren = 0子節點個數   c.set更新節點資料指令(執行後mtime、dataVersion可定會放生變化，dataLength可能會變化)    如：set /zk01 hellozk   d.delete刪除節點:注意：如果存在子節點，不讓刪除。只有刪除子節點後才能刪除。  如：delete /zk01   e.create指令補充：     普通持久節點:          如：create /zk03 ''     普通臨時節點：建立此臨時節點的客戶端失去和zk連線後，此節點消失.zk是通過臨時節點監控哪個伺服器掛掉的。  create -e /zk04 ''     順序持久節點：會根據使用者指定的節點路徑，自動分配一個遞增的順序號。（順序節點實現分散式鎖的效果，伺服器1搶到zk05分配zk050001，伺服器2搶到zk05分配zk050002） 如：create -s /zk05 ''     順序臨時節點：  create -s -e /zk06 'hello'   quit退出zk客戶端 4.zoo.cfg 配置zoo.cfg 配置說明： tickTime=2000  心跳間隔週期  毫秒。  initLimit=10初始連線超時閾值=10*tickTime。指的是follower初始連線leader的超時時間。 如果網路環境不好，適當調大。   syncLimit=5連線超時閾值=syncLimit*tickTime。指的是follower和leader做資料互動的超時時間。如果網路環境不好，適當調大。  dataDir=/usr/soft/zookeeper-3.4.7/tmp  dataDir資料目錄指的是zookeeper znode樹的持久化目錄， server.1=10.8.41.187:2888:3888 server.2=10.8.41.188:2888:3888 server.3=10.8.41.189:2888:3888 server後的數字是選舉id，在選舉過程中會用到。注意:數字一定要能比較出大小。  2888 埠原子廣播埠，可以自定義  3888 埠選舉埠，可以自定義 5.Zookeeper事務概念   a.每一個寫操作都是一個事務，每一個事務都用一個事務id來代表，叫：zxid    b.zxid 是全域性唯一，並且全域性遞增的。作用就是可以根據最大事務id，找到最新的事務 6.Zookeeper選舉機制   a.首先比較最大事務id，Zxid，誰大誰當領導    b.如果Zxid比較不出來，比較myid（選舉id），誰大誰當領導    c.選舉的前提滿足過半同意   選舉分兩個階段   a.資料恢復階段：     當zk伺服器啟動時，會先從本地磁碟找到本機的最大事務id。   b.選舉階段：      zk伺服器會提交選舉協議      1.Zxid（最大事務id） 2.本機的選舉id（myid檔案裡的數字） 3.邏輯時鐘值  記錄當前的選舉輪數，確保每個zk在同一輪選舉中 4.當前zk伺服器狀態，分4種：    Looking=>選舉階段 Following=>當小弟階段 Leading=>當領導階段 Observering=>觀察者階段(觀察者不參與選舉)   Leader:負責進行投票的發起和決議，更新系統狀態   follower:用於接收客戶端請求，並向客戶端返回結果，在選舉過程中參與投票   observer：可以接收客戶端連線，將寫請求轉發給Leader，但observer不參加投票過程，只同步Leader狀態，observer目的是為了擴充套件系統，提高讀取速度。      Leader選舉之後：   Leader身上肯定是有最新資料的（有最大事務id的），所以首先做的就是原子廣播（通過原子 廣播埠）。 原子廣播的目的就是為了確保資料一致性（即客戶端無論通過哪個zk伺服器檢視資料，資料都是一樣的）   目的二就是為了防止leader掛掉之後，資料的丟失問題   對於事務更新，Leader會通過原子廣播徵詢其他follower，只要滿足過半同意機制，事務才能被更新。 注意：a.若ZooKeeper叢集共有5臺機器，有三臺(半數以上的宕機了)，整個叢集就停止工作了。       b.若在一個Following上提交了更新事務，首先該Following會先將任務傳送Leader,由Leader會通過原子廣播徵詢其他follower，只要滿足過半同意機制，事務才能被更新操作。若是執行更新事務操作時，Leader掛掉，其它叢集伺服器執行完畢         後會將執行的結果交給Leader進行提交確認,但是Leader掛掉，此時事務會回滾。 7.Zxid 最大事務id 是全域性的， cZxid、mZxid、pZxid是針對某個節點路徑而言的。   擴充套件 Zookeeper的選舉機制根據Paxos 演算法來實現。    Paxos演算法解決的問題：在分散式環境下就某一個決議達成一致性問題。   Paxos演算法存在活鎖問題，Zk用的是Fast Paxos演算法，解決了活鎖問題。

8.zk的腦裂     腦裂的定義：在管理叢集裡，出現兩個Leader的狀況，造成資料混亂，造成整個叢集出現問題。腦裂問題是不可控和不可模擬的。出現腦裂問題的根源是選舉機制自叢集的選舉。   Zk腦裂的預防     為選舉的Leader分配遞增id，根據id的大小去判斷是否老Leader或新Leader，如果是老Leader， 就不接受其指令。 9、監控機制：         getData()：監控資料是否被修改         getChildren()：監控父節點下的子節點是否發生變化         exists()  ： 監控某個節點是否存在          一旦監控被觸發，若不重新置位，當再次發生同樣事件時，不會獲得觸發。 10.許可權控制：         ACL：訪問控制鏈【將所有許可權組織成為一個鏈條，對某一個節點提供不同許可權的定位，許可權取並集】                 定義許可權通過類似三元組來設計：（scheme:expression, prems） 模式：使用者, 許可權         模式：world[預設所有的成員訪問都是anyone]，auth,digest[通過使用者名稱，密碼訪問 也叫訪客模式], host [通過域名]，ip         許可權：create, read, write, delete, admin

11.ZooKeeper應用場景   11.1 實現訊息訂閱和釋出實現思路：     a.建立一個znode節點  /data     b.其他訂閱節點監聽/data 節點的資料變化事件      c.如果有事件發生，就獲取/data節點的資料   11.2 實現叢集整體的配置資訊管理     比如某一個機器的配置資訊發生變化，其他機器的配置資訊也實現同步更改。 實現思路同上   11.3 叢集管理     能夠快速檢測出叢集裡節點的狀態      實現思路：      臨時節點+監聽機制   11.4 實現分散式訊息的協調通知（屏障）   11.5 實現叢集的負載均衡     a.利用zk檢測到每臺的機器的負載情況，指標是：cpu和記憶體。      b.每臺客戶端定期將自己的負載情況指標發給zk      c.zk根據收集到指標後，根據負載情況做相關業務控制     11.6 實現分散式鎖     實現思路： 利用順序臨時節點的特性來實現，比如4個客戶端爭相搶注  /source 順序臨時節點。最先搶注的順序號最小， 就分配給這個節點資源，     該節點對應的伺服器執行完後，session會話斷開，對應的/source001的臨時節點就銷燬。接下來，/source002節點對應的伺服器執行操作。  11.7 實現命名服務     利用znode路徑的唯一性，來做命名服務。   11.8 zk不適用於做的事情     不能用zk儲存大量資料。znode樹是維繫在記憶體裡的，如果資料大，會吃掉大量記憶體。 12.ZooKeeper 特性     a.資料一致性（單一檢視）       client不論連線到哪個Zookeeper，展示給它都是同一個檢視，即查詢的資料都是一樣的。這是zookeeper最重要的效能。     b.原子性       對於事務決議的更新，只能是成功或者失敗兩種可能，沒有中間狀態。要麼都更新成功，要麼都不更新。     c.可靠性       一旦服務端成功的應用了一個事務，並完成對客戶端的響應，那麼該事務所引起的服務端狀態 變更將會一直保留下來，除非有另一個事務又對其進行了改變。     d.實時性       Zookeeper保證客戶端將在非常短的時間間隔範圍內獲得伺服器的更新資訊，或者伺服器失效 的資訊，或者指定監聽事件的變化資訊。（前提條件是：網路狀況良好）     e.過半性       叢集必須有半數以上的機器存活才能正常工作。因為只有滿足過半數，才能滿足選舉機制選出Leader。因為只有過半，在做事務決議時，事務才能更新。       所以一般來說，zookeeper叢集的數量最好是奇數個。