11. Chroot 特性

3.2.0 版本后，添加了 Chroot 特性，該特性允許每個客戶端為自己設置一個命名空間。如果一個客戶端設置了 Chroot，那么該客戶端對服務器的任何操作，都將會被限制在其自己的命名空間下。

通過設置 Chroot，能夠將一個客戶端應用于 Zookeeper 服務端的一顆子樹相對應，在那些多個應用公用一個 Zookeeper 進群的場景下，對實現不同應用間的相互隔離非常有幫助。

12. 會話管理

分桶策略：將類似的會話放在同一區塊中進行管理，以便于 Zookeeper 對會話進行不同區塊的隔離處理以及同一區塊的統一處理。

分配原則：每個會話的“下次超時時間點”（ExpirationTime）

計算公式：

ExpirationTime_ = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *

ExpirationInterval , ExpirationInterval 是指 Zookeeper 會話超時檢查時間間隔，默認 tickTime

13. 服務器角色

Leader

1、事務請求的唯一調度和處理者，保證集群事務處理的順序性

2、集群內部各服務的調度者

Follower

1、處理客戶端的非事務請求，轉發事務請求給 Leader 服務器

2、參與事務請求 Proposal 的投票

3、參與 Leader 選舉投票

Observer

1、3.0 版本以后引入的一個服務器角色，在不影響集群事務處理能力的基礎上提升集群的非事務處理能力

2、處理客戶端的非事務請求，轉發事務請求給 Leader 服務器

3、不參與任何形式的投票

14. Zookeeper 下 Server 工作狀態

服務器具有四種狀態，分別是 LOOKING、FOLLOWING、LEADING、OBSERVING。

1、LOOKING：尋找 Leader 狀態。當服務器處于該狀態時，它會認為當前集群中沒有 Leader，因此需要進入 Leader 選舉狀態。

2、FOLLOWING：跟隨者狀態。表明當前服務器角色是 Follower。

3、LEADING：領導者狀態。表明當前服務器角色是 Leader。

4、OBSERVING：觀察者狀態。表明當前服務器角色是 Observer。

15. 數據同步

整個集群完成 Leader 選舉之后，Learner（Follower 和 Observer 的統稱）回向Leader 服務器進行注冊。當 Learner 服務器想 Leader 服務器完成注冊后，進入數據同步環節。

數據同步流程：（均以消息傳遞的方式進行）

Learner 向 Learder 注冊

數據同步

同步確認

Zookeeper 的數據同步通常分為四類：

1、直接差異化同步（DIFF 同步）

2、先回滾再差異化同步（TRUNC+DIFF 同步）

3、僅回滾同步（TRUNC 同步）

4、全量同步（SNAP 同步）

在進行數據同步前，Leader 服務器會完成數據同步初始化：

peerLastZxid：

從 learner 服務器注冊時發送的 ACKEPOCH 消息中提取 lastZxid（該Learner 服務器最后處理的 ZXID）

minCommittedLog：

Leader 服務器 Proposal 緩存隊列 committedLog 中最小 ZXID

maxCommittedLog：

Leader 服務器 Proposal 緩存隊列 committedLog 中最大 ZXID

直接差異化同步（DIFF 同步）

場景：peerLastZxid 介于 minCommittedLog 和 maxCommittedLog之間

先回滾再差異化同步（TRUNC+DIFF 同步）

場景：當新的 Leader 服務器發現某個 Learner 服務器包含了一條自己沒有的事務記錄，那么就需要讓該 Learner 服務器進行事務回滾–回滾到 Leader服務器上存在的，同時也是最接近于 peerLastZxid 的 ZXID

僅回滾同步（TRUNC 同步）

場景：peerLastZxid 大于 maxCommittedLog

全量同步（SNAP 同步）

場景一：peerLastZxid 小于 minCommittedLog

場景二：Leader 服務器上沒有 Proposal 緩存隊列且 peerLastZxid 不等于 lastProcessZxid

16. zookeeper 是如何保證事務的順序一致性的？

zookeeper 采用了全局遞增的事務 Id 來標識，所有的 proposal（提議）都在被提出的時候加上了 zxid，zxid 實際上是一個 64 位的數字，高 32 位是 epoch（時期; 紀元; 世; 新時代）用來標識 leader 周期，如果有新的 leader 產生出來，epoch會自增，低 32 位用來遞增計數。當新產生 proposal 的時候，會依據數據庫的兩階段過程，首先會向其他的 server 發出事務執行請求，如果超過半數的機器都能執行并且能夠成功，那么就會開始執行。

17. 分布式集群中為什么會有 Master？

在分布式環境中，有些業務邏輯只需要集群中的某一臺機器進行執行，其他的機器可以共享這個結果，這樣可以大大減少重復計算，提高性能，于是就需要進行leader 選舉。

18. zk 節點宕機如何處理？

Zookeeper 本身也是集群，推薦配置不少于 3 個服務器。Zookeeper 自身也要保證當一個節點宕機時，其他節點會繼續提供服務。

如果是一個 Follower 宕機，還有 2 臺服務器提供訪問，因為 Zookeeper 上的數據是有多個副本的，數據并不會丟失；

如果是一個 Leader 宕機，Zookeeper 會選舉出新的 Leader。ZK 集群的機制是只要超過半數的節點正常，集群就能正常提供服務。只有在 ZK節點掛得太多，只剩一半或不到一半節點能工作，集群才失效。所以3 個節點的 cluster 可以掛掉 1 個節點(leader 可以得到 2 票>1.5)

2 個節點的 cluster 就不能掛掉任何 1 個節點了(leader 可以得到 1 票<=1)

19. zookeeper 負載均衡和 nginx 負載均衡區別

zk 的負載均衡是可以調控，nginx 只是能調權重，其他需要可控的都需要自己寫插件；但是 nginx 的吞吐量比 zk 大很多，應該說按業務選擇用哪種方式。

20. Zookeeper 有哪幾種幾種部署模式？

部署模式：單機模式、偽集群模式、集群模式。