1. zookeeper 節點有什麼用
ZooKeeper 節點是有生命周期的，這取決於節點的類型。在 ZooKeeper 中，節點類型可以分為持久節點（PERSISTENT ）、臨時節點（EPHEMERAL），以及時序節點（SEQUENTIAL ），具體在節點創建過程中，一般是組合使用，可以生成以下 4 種節點類型。
持久節點（PERSISTENT）
所謂持久節點，是指在節點創建後，就一直存在，直到有刪除操作來主動清除這個節點——不會因為創建該節點的客戶端會話失效而消失。
持久順序節點（PERSISTENT_SEQUENTIAL）
這類節點的基本特性和上面的節點類型是一致的。額外的特性是，在ZK中，每個父節點會為他的第一級子節點維護一份時序，會記錄每個子節點創建的先後順序。基於這個特性，在創建子節點的時候，可以設置這個屬性，那麼在創建節點過程中，ZK會自動為給定節點名加上一個數字後綴，作為新的節點名。這個數字後綴的范圍是整型的最大值。
臨時節點（EPHEMERAL）
和持久節點不同的是，臨時節點的生命周期和客戶端會話綁定。也就是說，如果客戶端會話失效，那麼這個節點就會自動被清除掉。注意，這里提到的是會話失效，而非連接斷開。另外，在臨時節點下面不能創建子節點。
臨時順序節點（EPHEMERAL_SEQUENTIAL）
可以用來實現分布式鎖
客戶端調用create()方法創建名為「_locknode_/guid-lock-」的節點，需要注意的是，這里節點的創建類型需要設置為EPHEMERAL_SEQUENTIAL。
客戶端調用getChildren(「_locknode_」)方法來獲取所有已經創建的子節點，注意，這里不注冊任何Watcher。
客戶端獲取到所有子節點path之後，如果發現自己在步驟1中創建的節點序號最小，那麼就認為這個客戶端獲得了鎖。
如果在步驟3中發現自己並非所有子節點中最小的，說明自己還沒有獲取到鎖。此時客戶端需要找到比自己小的那個節點，然後對其調用exist()方法，同時注冊事件監聽。
之後當這個被關注的節點被移除了，客戶端會收到相應的通知。這個時候客戶端需要再次調用getChildren(「_locknode_」)方法來獲取所有已經創建的子節點，確保自己確實是最小的節點了，然後進入步驟3。
2. zookeeper集群，分布式鎖怎麼保證正確
1. 利用節點名稱的唯一性來實現共享鎖
ZooKeeper抽象出來的節點結構是一個和unix文件系統類似的小型的樹狀的目錄結構。ZooKeeper機制規定：同一個目錄下只能有一個唯一的文件名。例如：我們在Zookeeper目錄/test目錄下創建，兩個客戶端創建一個名為Lock節點，只有一個能夠成功。
演算法思路: 利用名稱唯一性，加鎖操作時，只需要所有客戶端一起創建/test/Lock節點，只有一個創建成功，成功者獲得鎖。解鎖時，只需刪除/test/Lock節點，其餘客戶端再次進入競爭創建節點，直到所有客戶端都獲得鎖。
基於以上機制，利用節點名稱唯一性機制的共享鎖演算法流程如圖所示：
該共享鎖實現很符合我們通常多個線程去競爭鎖的概念，利用節點名稱唯一性的做法簡明、可靠。
由上述演算法容易看出，由於客戶端會同時收到/test/Lock被刪除的通知，重新進入競爭創建節點，故存在"驚群現象"。
使用該方法進行測試鎖的性能列表如下：
總結 這種方案的正確性和可靠性是ZooKeeper機制保證的，實現簡單。缺點是會產生「驚群」效應，假如許多客戶端在等待一把鎖，當鎖釋放時候所有客戶端都被喚醒，僅僅有一個客戶端得到鎖。
2. 利用臨時順序節點實現共享鎖的一般做法
首先介紹一下，Zookeeper中有一種節點叫做順序節點，故名思議，假如我們在/lock/目錄下創建節3個點，ZooKeeper集群會按照提起創建的順序來創建節點，節點分別為/lock/0000000001、/lock/0000000002、/lock/0000000003。
ZooKeeper中還有一種名為臨時節點的節點，臨時節點由某個客戶端創建，當客戶端與ZooKeeper集群斷開連接，則開節點自動被刪除。
利用上面這兩個特性，我們來看下獲取實現分布式鎖的基本邏輯：
客戶端調用create()方法創建名為「locknode/guid-lock-」的節點，需要注意的是，這里節點的創建類型需要設置為EPHEMERAL_SEQUENTIAL。
客戶端調用getChildren(「locknode」)方法來獲取所有已經創建的子節點，同時在這個節點上注冊上子節點變更通知的Watcher。
客戶端獲取到所有子節點path之後，如果發現自己在步驟1中創建的節點是所有節點中序號最小的，那麼就認為這個客戶端獲得了鎖。
如果在步驟3中發現自己並非是所有子節點中最小的，說明自己還沒有獲取到鎖，就開始等待，直到下次子節點變更通知的時候，再進行子節點的獲取，判斷是否獲取鎖。
釋放鎖的過程相對比較簡單，就是刪除自己創建的那個子節點即可。
上面這個分布式鎖的實現中，大體能夠滿足了一般的分布式集群競爭鎖的需求。這里說的一般性場景是指集群規模不大，一般在10台機器以內。
不過，細想上面的實現邏輯，我們很容易會發現一個問題，步驟4，「即獲取所有的子點，判斷自己創建的節點是否已經是序號最小的節點」，這個過程，在整個分布式鎖的競爭過程中，大量重復運行，並且絕大多數的運行結果都是判斷出自己並非是序號最小的節點，從而繼續等待下一次通知——這個顯然看起來不怎麼科學。客戶端無端的接受到過多的和自己不相關的事件通知，這如果在集群規模大的時候，會對Server造成很大的性能影響，並且如果一旦同一時間有多個節點的客戶端斷開連接，這個時候，伺服器就會像其餘客戶端發送大量的事件通知——這就是所謂的驚群效應。而這個問題的根源在於，沒有找准客戶端真正的關注點。
3. 如何實現一個zookeeper的分布式鎖
1. 利用節點名稱的唯一性來實現共享鎖
ZooKeeper抽象出來的節點結構是一個和unix文件系統類似的小型的樹狀的目錄結構。ZooKeeper機制規定：同一個目錄下只能有一個唯一的文件名。例如：我們在Zookeeper目錄/test目錄下創建，兩個客戶端創建一個名為Lock節點，只有一個能夠成功。
演算法思路: 利用名稱唯一性，加鎖操作時，只需要所有客戶端一起創建/test/Lock節點，只有一個創建成功，成功者獲得鎖。解鎖時，只需刪除/test/Lock節點，其餘客戶端再次進入競爭創建節點，直到所有客戶端都獲得鎖。
基於以上機制，利用節點名稱唯一性機制的共享鎖演算法流程如圖所示：
該共享鎖實現很符合我們通常多個線程去競爭鎖的概念，利用節點名稱唯一性的做法簡明、可靠。
由上述演算法容易看出，由於客戶端會同時收到/test/Lock被刪除的通知，重新進入競爭創建節點，故存在"驚群現象"。
使用該方法進行測試鎖的性能列表如下：
總結 這種方案的正確性和可靠性是ZooKeeper機制保證的，實現簡單。缺點是會產生「驚群」效應，假如許多客戶端在等待一把鎖，當鎖釋放時候所有客戶端都被喚醒，僅僅有一個客戶端得到鎖。
2. 利用臨時順序節點實現共享鎖的一般做法
首先介紹一下，Zookeeper中有一種節點叫做順序節點，故名思議，假如我們在/lock/目錄下創建節3個點，ZooKeeper集群會按照提起創建的順序來創建節點，節點分別為/lock/0000000001、/lock/0000000002、/lock/0000000003。
ZooKeeper中還有一種名為臨時節點的節點，臨時節點由某個客戶端創建，當客戶端與ZooKeeper集群斷開連接，則開節點自動被刪除。
利用上面這兩個特性，我們來看下獲取實現分布式鎖的基本邏輯：
客戶端調用create()方法創建名為「locknode/guid-lock-」的節點，需要注意的是，這里節點的
4. zookeeper 臨時節點 多久刪除
如/myapp/data/1，在創建節點的時候還可以指定節點的類型：是永久節點，永久順序節點，臨時節點，臨時順序節點。
這個節點類型是非常強大的。永久節點一經創建就永久保留了，就像我們在文件系統上創建一個普通文件，這個文件的生命周期跟創建它的應用沒有任何關系。
而臨時節點呢，當創建這個臨時節點的應用與zookeeper之間的會話過期之後就會被zookeeper自動刪除了。
5. zookeeper創建有序節點，序號是否會被用完
ZooKeeper 節點是有生命周期的，這取決於節點的類型。在 ZooKeeper 中，節點類型可以分為持久節點（PERSISTENT ）、臨時節點（EPHEMERAL），以及時序節點（SEQUENTIAL ），具體在節點創建過程中，一般是組合使用，可以生成以下 4 種節點類型。
持久節點（PERSISTENT）
所謂持久節點，是指在節點創建後，就一直存在，直到有刪除操作來主動清除這個節點——不會因為創建該節點的客戶端會話失效而消失。
持久順序節點（PERSISTENT_SEQUENTIAL）
這類節點的基本特性和上面的節點類型是一致的。額外的特性是，在ZK中，每個父節點會為他的第一級子節點維護一份時序，會記錄每個子節點創建的先後順序。基於這個特性，在創建子節點的時候，可以設置這個屬性，那麼在創建節點過程中，ZK會自動為給定節點名加上一個數字後綴，作為新的節點名。這個數字後綴的范圍是整型的最大值。
臨時節點（EPHEMERAL）
和持久節點不同的是，臨時節點的生命周期和客戶端會話綁定。也就是說，如果客戶端會話失效，那麼這個節點就會自動被清除掉。注意，這里提到的是會話失效，而非連接斷開。另外，在臨時節點下面不能創建子節點。
臨時順序節點（EPHEMERAL_SEQUENTIAL）
可以用來實現分布式鎖
客戶端調用create()方法創建名為「_locknode_/guid-lock-」的節點，需要注意的是，這里節點的創建類型需要設置為EPHEMERAL_SEQUENTIAL。
客戶端調用getChildren(「_locknode_」)方法來獲取所有已經創建的子節點，注意，這里不注冊任何Watcher。
客戶端獲取到所有子節點path之後，如果發現自己在步驟1中創建的節點序號最小，那麼就認為這個客戶端獲得了鎖。
如果在步驟3中發現自己並非所有子節點中最小的，說明自己還沒有獲取到鎖。此時客戶端需要找到比自己小的那個節點，然後對其調用exist()方法，同時注冊事件監聽。
之後當這個被關注的節點被移除了，客戶端會收到相應的通知。這個時候客戶端需要再次調用getChildren(「_locknode_」)方法來獲取所有已經創建的子節點，確保自己確實是最小的節點了，然後進入步驟3。
6. 如何判斷zookeeper節點是持久節點還是臨時節點
zookeeper 持久節點：該數據節點被創建後，就會一直存在於zookeeper伺服器上，直到有刪除操作來主動刪除這個節點。
zookeeper臨時節點：臨時節點的生命周期和客戶端會話綁定在一起，客戶端會話失效，則這個節點就會被自動清除。
我們執行 sh zkCli.sh -server 127.0.0.1:2181登錄zookeeper，分別創建一個持久節點和臨時節點。
create /yujie-persistent "" //創建持久節點
create -e /yujie-ephemeral "" // 創建臨時節點
7. zookeeper 到底是個什麼
1. 什麼是Zookeeper
大數據集群包括多種類型的服務節點，如何協調各節點之間的服務，需要一種強有力的工具來完成。如果我們把大數據集群中的每個服務節點當作一種動物，那麼ZooKeeper便是這里的動物管理員了。藉助網路的定義，ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務。
Zookeeper提供的服務功能有：
1) 數據注冊功能;
2) 數據查詢功能;
3) 數據監聽功能;
Zookeeper能用來做什麼：
a) 分布式系統中主從協調
b) 分布式系統中配置信息同步
c) 分布式系統中分布式共享鎖(Master選舉)
d) 分布式系統中負載均衡
e) 分布式系統中明名稱服務
2. Zookeeper的數據組織形式
Zookeeper的數據存儲形式是key-value， key類型與平時我們看到的類型不太一樣，這里是一種類似路徑的形式，如」/aa/bb」。 value值是byte[]位元組數組類型。 我們稱它為ZNode。
ZNode根據其特點不同，可以分為三種類型：持久(persistent)節點、順序(sequential)節點和臨時(ephemeral)節點。
持久節點: 一經創建，就會一直存儲，除非客戶端主動刪除該節點。
順序節點：客戶端在創建此類節點時，會在該節點後拼接上一個序號，類似/aa0000000001，/aa0000000002...
臨時節點：創建此類節點時，客戶端必須和zookeeper服務端保持心跳。
其中還可以將這三種節點進行組合：
永久節點+順序節點;
臨時節點+順序節點;
8. zookeeper 臨時節點多長時間能夠刪掉
（1）解壓為zookeepertar -xf -C /home/myuser/zookeeper/ 復制zookeeper文件夾3份，分別重名名為zookeeperA，zookeeperB，zookeeperC。 並且創建數據快照以及日誌存放文件夾，命名為zooA，zooB，zooC。 （2）編輯對應的zookeeper配置文件
9. Consul和ZooKeeper，Doozerd，Etcd的區別
ZooKeeper、Doozerd、Etcd在架構上都非常相似，它們都有服務節點（server node），而這些服務節點的操作都要求達到節點的仲裁數（通常，節點的仲裁數遵循的是簡單多數原則）。此外，它們都是強一致性的，並且提供各種原語。通過應用程序內部的客戶端lib庫，這些原語可以用來構建復雜的分布式系統。
Consul在一個單一的數據中心內部使用服務節點。在每個數據中心中，為了Consule能夠運行，並且保持強一致性，Consul服務端需要仲裁。然而，Consul原生支持多數據中心，就像一個豐富gossip系統連接伺服器節點和客戶端一樣。
當提供K/V存儲的時候，這些系統具有大致相同的語義，讀取是強一致性的，並且在面對網路分區的時候，為了保持一致性，讀取的可用性是可以犧牲的。然而，當系統應用於復雜情況時，這種差異會變得更加明顯。
這些系統提供的語義對開發人員構建服務發現系統很有吸引力，但更重要的是，強調開發人員要構建這些特性。ZooKeeper
只提供一個原始的K/V值存儲，並要求開發人員構建他們自己的系統來提供服務發現功能。相反的是，Consul提供了一個堅固的框架，這不僅僅是為了提供
服務發現功能，也是為了減少推測工作和開發工作量。客戶端只需簡單地完成服務注冊工作，然後使用一個DNS介面或者HTTP介面就可以執行工作了，而其他
系統則需要你定製自己的解決方案。
一個令人信服的服務發現框架必須包含健康檢測功能，並且考慮失敗的可能性。要是節點失敗或者服務故障了，即使開發人員知道節點A提供Foo服務也是沒用的。Navie系統利用的是心跳、周期性更新和TTLs，這些系統不僅需要工作量與節點數量成線性關系，並且對伺服器的固定數量提出了要求。此外，故障檢測窗口的存活時間至少要和TTL一樣長。
ZooKeeper提供了臨時節點，這些臨時節點就是K/V條目，當客戶端斷開連接時，這些條目會被刪除。雖
然這些臨時節點比一個心跳系統更高級，但仍存在固有的擴展性問題，並且會增加客戶端的復雜性。與ZooKeeper伺服器端連接時，客戶端必須保持活躍，
並且去做持續性連接。此外，ZooKeeper還需要胖客戶端，而胖客戶端是很難編寫，並且胖客戶端會經常導致調試質詢。
Consul使用一個完全不同的架構進行健康檢測。Consul
客戶端可以運行在集群中的每一個節點上，而不是擁有伺服器節點，這些Consul客戶端屬於一個gossip pool，gossip
pool提供了一些功能，包括分布式健康檢測。gossip協議提供了一個高效的故障檢測工具，這個故障檢測工具可以應用到任意規模的集群，而不僅僅是作
用於特定的伺服器組。同時，這個故障檢測工具也支持在本地進行多種健康檢測。與此相反，ZooKeeper的臨時節點只是一個非常原始的活躍度檢測。因為
有了Consul，客戶端可以檢測web伺服器是否正在返回200狀態碼，內存利用率是否達到臨界點，是否有足夠的數據存儲盤等。此
外，ZooKeeper會暴露系統的復雜性給客戶端，為了避免ZooKeeper出現的這種情況，Consul只提供一個簡單HTTP介面。
Consul為服務發現、健康檢測、K/V存儲和多數據中心提供了一流的支持。為
了支持任意存儲，而不僅僅是簡單的K/V存儲，其他系統都要求工具和lib庫要率先建立。然而，通過使用客戶端節點，Consul提供了一個簡單的
API，這個API的開發只需要瘦客戶端就可以了，
而且，通過使用配置文件和DNS介面，開發人員可以建立完整的服務發現解決方案，最終，達到避免開發API的目的。