zookeeper如何注冊伺服器

① zqat伺服器怎麼注冊

zqat伺服器注冊方法如下
1.linux上安裝 Zookeeper，Zookeeper是一個分布式協調工具，可以實現注冊中心功能，所以可以取代Eureka伺服器，作為服務注冊與發現中心。
2.在項目模塊 pom.xml中添加zookeeper 依賴。

② 如何啟動zookeeper-3.3.6

如何啟動zookeeper-3.3.6？

啟動zookeeper-3.3.6的方法：下載安裝配置zookeeper的伺服器環境-創建文件-設置許可權-編輯-重啟即可。

具體步驟：

一、登陸linux伺服器用cd 命令切換到/etc/rc.d/init.d/目錄下。

十、重啟即可。

③ Zookeeper深入原理

Zookeeper 的視圖結構是一個樹形結構，樹上的每個節點稱之為數據節點（即 ZNode），每個ZNode 上都可以保存數據，同時還可以掛載子節點。並且Zookeeper的根節點為 "/"。

在 Zookeeper 中，每個數據節點都是有生命周期的，其生命周期的長短取決於數據節點的節點類型。在 Zookeeper 中有如下幾類節點：

每個數據節點中除了存儲了數據內容之外，還存儲了數據節點本身的一些狀態信息（State）。

在Zookeeper 中，事務是指能夠改變 Zookeeper 伺服器狀態的操作，我們也稱之為事務操作或更新操作，一般包括數據節點創建與刪除、數據節點內容更新和客戶端會話創建與失效等操作。對於每一個事務請求，Zookeeper 都會為其分配一個全局唯一的事務ID，用 ZXID 來表示，通常是一個 64 位的數字。每一個 ZXID 對應一次更新操作，從這些 ZXID 中可以間接地識別出 Zookeeper 處理這些更新操作請求的全局順序。

ZXID 是一個 64 位的數字，其中低 32 位可以看作是一個簡單的單調遞增的計數器，針對客戶端的每一個事務請求，Leader 伺服器在產生一個新的事務 Proposal 的時候，都會對該計數器進行加 1 操作；而高 32 位則代表了 Leader 周期 epoch 的編號，每當選舉產生一個新的 Leader 伺服器，就會從這個 Leader 伺服器上取出其本地日誌中最大事務 Proposal 的 ZXID，並從該 ZXID 中解析出對應的 epoch 值，然後再對其進行加 1 操作，之後就會以此編號作為新的 epoch，並將低 32 位置 0 來開始生成新的 ZXID。

Zookeeper 中為數據節點引入了版本的概念，每個數據節點都具有三種類型的版本信息（在上面的狀態信息中已經介紹了三種版本信息代表的意思），對數據節點的任何更新操作都會引起版本號的變化。其中我們以 dataVersion 為例來說明。在一個數據節點被創建完畢之後，節點的dataVersion 值是 0，表示的含義是 」當前節點自從創建之後，被更新過 0 次「。如果現在對該節點的數據內容進行更新操作，那麼隨後，dataVersion 的值就會變成 1。即表示的是對數據節點的數據內容的變更次數。

版本的作用是用來實現樂觀鎖機制中的 「寫入校驗」 的。例如，當要修改數據節點的數據內容時，帶上版本號，如果數據節點的版本號與傳入的版本號相等，就進行修改，否則修改失敗。

Zookeeper 提供了分布式數據的發布/訂閱功能。一個典型的發布/訂閱模型系統定義了一種一對多的訂閱關系，能夠讓多個訂閱者同時監聽某一個主題對象，當這個主題對象自身狀態變化時，會通知所有訂閱者，使它們能夠做出相應的處理。在 Zookeeper 中，引入了 Watcher 機制來實現這種分布式的通知功能。Zookeeper 允許客戶端向服務端注冊一個 Watcher 監聽，當服務端的一些指定事件觸發了這個 Watcher，那麼就會向指定客戶端發送一個事件通知來實現分布式的通知功能。

從上圖可以看出 Zookeeper 的 Watcher 機制主要包括客戶端線程、客戶端WatchMananger 和 Zookeeper 伺服器三部分。在具體工作流程上，簡單地講，客戶端在向 Zookeeper 伺服器注冊 Watcher 的同時，會將 Watcher 對象存儲在客戶端的 WatchMananger 中。當 Zookeeper 伺服器端觸發 Watcher 事件後，會向客戶端發送通知，客戶端線程從 WatchManager 中取出對應的 Watcher 對象來執行回調邏輯。

Watcher是一個介面，任何實現了Watcher介面的類就是一個新的Watcher。Watcher內部包含了兩個枚舉類：KeeperState、EventType

注 ：客戶端接收到的相關事件通知中只包含狀態及類型等信息，不包括節點變化前後的具體內容，變化前的數據需業務自身存儲，變化後的數據需調用get等方法重新獲取；

上面講到zookeeper客戶端連接的狀態和zookeeper對znode節點監聽的事件類型，下面我們來講解如何建立zookeeper的watcher監聽。在zookeeper中採用zk.getChildren(path, watch)、zk.exists(path, watch)、zk.getData(path, watcher, stat)這樣的方式為某個znode注冊監聽。

下表以node-x節點為例，說明調用的注冊方法和可監聽事件間的關系：

Zookeeper 中提供了一套完善的 ACL（Access Control List）許可權控制機制來保障數據的安全。

ACL 由三部分組成，分別是：許可權模式（Scheme）、授權對象（ID）和許可權（Permission），通常使用「scheme: ​id:permission」來標識一個有效的ACL 信息。下面分別介紹：

1.7.4、ACL 超級管理員

zookeeper的許可權管理模式有一種叫做super，該模式提供一個超管可以方便的訪問任何許可權的節點

假設這個超管是：super:admin，需要先為超管生成密碼的密文

那麼打開zookeeper目錄下的/bin/zkServer.sh伺服器腳本文件，找到如下一行：

這就是腳本中啟動zookeeper的命令，默認只有以上兩個配置項，我們需要加一個超管的配置項

那麼修改以後這條完整命令變成了

之後啟動zookeeper,輸入如下命令添加許可權

在伺服器集群初始化階段，我們以 3 台機器組成的伺服器集群為例，當有一台伺服器server1 啟動的時候，它是無法進行 Leader 選舉的，當第二台機器 server2 也啟動時，此時這兩台伺服器已經能夠進行互相通信，每台機器都試圖找到一個 Leader，於是便進入了 Leader 選舉流程。

在zookeeper運行期間，leader與非leader伺服器各司其職，即便當有非leader伺服器宕機或新加入，此時也不會影響leader，但是一旦leader伺服器掛了，那麼整個集群將暫停對外服務，進入新一輪leader選舉，其過程和啟動時期的Leader選舉過程基本一致。

假設正在運行的有server1、server2、server3三台伺服器，當前leader是server2，若某一時刻leader掛了，此時便開始Leader選舉。選舉過程如下:

observer角色特點：

為了使用observer角色，在任何想變成observer角色的配置文件中加入如下配置：

並在所有server的配置文件中，配置成observer模式的server的那行配置追加:observer，例如：