前言
大公司面試特別喜歡問 Zookeeper，因為 Zookeeper 確實是足夠的優秀，比如他的 Paxos 算法，Zab 協議，Leader 選舉策略，分布式鎖等都是大廠面試的高頻考點。我們不僅需要熟悉使用 Zookeeper，更要了解他的底層原理，這樣不論是工作還是學習都是游刃有余。
小編分享的這份2022年Java秋招備戰面試題總計有1000多道面試題，包含了MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Java 并發編程、Java基礎、Spring、微服務、Linux、Spring Boot 、Spring Cloud、RabbitMQ、kafka等16個專題技術點，都是小編在今年金三銀四總結出來的面試真題，已經有很多粉絲靠這份PDF拿下眾多大廠的offer，今天在這里總結分享給到大家！【持續更新中！】
| 序號 | 專題技術 | 內容 | 地址 |
|---|---|---|---|
| 1 | MyBatis | Mybatis面試題 | http://www.lxweimin.com/p/0cae6fd558b1 |
| 2 | ZooKeeper | ZooKeeper面試題 |
1、ZooKeeper 面試題？
ZooKeeper 是一個開放源碼的分布式協調服務，它是集群的管理者，監視著集群 中各個節點的狀態根據節點提交的反饋進行下一步合理操作。最終，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。
分布式應用程序可以基于 Zookeeper 實現諸如數據發布/訂閱、負載均衡、命名服務、分布式協調/通知、集群管理、Master 選舉、分布式鎖和分布式隊列等功能。
Zookeeper 保證了如下分布式一致性特性：
1、順序一致性
2、原子性
3、單一視圖
4、可靠性
5、實時性（最終一致性）
客戶端的讀請求可以被集群中的任意一臺機器處理，如果讀請求在節點上注冊了監聽器，這個監聽器也是由所連接的 zookeeper 機器來處理。對于寫請求，這些請求會同時發給其他 zookeeper 機器并且達成一致后，請求才會返回成功。因此，隨著 zookeeper 的集群機器增多，讀請求的吞吐會提高但是寫請求的吞吐會下降。
有序性是 zookeeper 中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯一的時間戳，這個時間戳稱為 zxid（Zookeeper Transaction Id）。而讀請求只會相對于更新有序，也就是讀請求的返回結果中會帶有這個zookeeper 最新的 zxid。
2、ZooKeeper提供了什么？
1、文件系統
2、通知機制
3、Zookeeper文件系統
4、ZAB協議？
5、四種類型的數據節點 Znode
4、EPHEMERAL_SEQUENTIAL-臨時順序節點
基本特性同臨時節點，增加了順序屬性，節點名后邊會追加一個由父節點維護的自增整型數字。
6、Zookeeper Watcher 機制 -- 數據變更通知
工作機制：
1、客戶端注冊 watcher
2、服務端處理 watcher
3、客戶端回調 watcher
Watcher 特性總結：
1、一次性
無論是服務端還是客戶端，一旦一個 Watcher 被觸發，Zookeeper 都會將其從相應的存儲中移除。這樣的設計有效的減輕了服務端的壓力，不然對于更新非常頻繁的節點，服務端會不斷的向客戶端發送事件通知，無論對于網絡還是服務端的
壓力都非常大。
2、客戶端串行執行
客戶端 Watcher 回調的過程是一個串行同步的過程。
3、輕量
3.1、Watcher 通知非常簡單，只會告訴客戶端發生了事件，而不會說明事件的具
體內容。
3.2、客戶端向服務端注冊 Watcher 的時候，并不會把客戶端真實的 Watcher 對
象實體傳遞到服務端，僅僅是在客戶端請求中使用 boolean 類型屬性進行了標記。
4、watcher event 異步發送 watcher 的通知事件從 server 發送到 client 是異步的，這就存在一個問題，不同的客戶端和服務器之間通過 socket 進行通信，由于網絡延遲或其他因素導致客戶端在不通的時刻監聽到事件，由于 Zookeeper 本身提供了 ordering guarantee，即客戶端監聽事件后，才會感知它所監視 znode發生了變化。所以我們使用 Zookeeper 不能期望能夠監控到節點每次的變化。 Zookeeper 只能保證最終的一致性，而無法保證強一致性。
5、注冊 watcher getData、exists、getChildren
6、觸發 watcher create、delete、setData
7、當一個客戶端連接到一個新的服務器上時，watch 將會被以任意會話事件觸發。當與一個服務器失去連接的時候，是無法接收到 watch 的。而當 client 重新連接時，如果需要的話，所有先前注冊過的 watch，都會被重新注冊。通常這是完全透明的。只有在一個特殊情況下，watch 可能會丟失：對于一個未創建的 znode的 exist watch，如果在客戶端斷開連接期間被創建了，并且隨后在客戶端連接上之前又刪除了，這種情況下，這個 watch 事件可能會被丟失。
7、客戶端注冊Watcher實現
8、服務端處理Watcher實現
9、客戶端回調Watche
客戶端 SendThread 線程接收事件通知，交由 EventThread 線程回調 Watcher。 客戶端的 Watcher 機制同樣是一次性的，一旦被觸發后，該 Watcher 就失效了。
10、ACL權限控制機制
2、DELETE：子節點刪除權限，允許授權對象刪除該數據節點的子節點
3、READ：數據節點的讀取權限，允許授權對象訪問該數據節點并讀取其數據內容或子節點列表等
4、WRITE：數據節點更新權限，允許授權對象對該數據節點進行更新操作
5、ADMIN：數據節點管理權限，允許授權對象對該數據節點進行 ACL 相關設置操作
11、Chroot特性
12、會話管理
ExpirationTime_ = currentTime + sessionTimeout
ExpirationTime = (ExpirationTime_ / ExpirationInrerval + 1) *
ExpirationInterval , ExpirationInterval 是指 Zookeeper 會話超時檢查時間間隔，默認 tickTime
13、服務器角色
14、Zookeeper 下 Server工作狀態
服務器具有四種狀態，分別是 LOOKING、FOLLOWING、LEADING、OBSERVING。
1、LOOKING：尋找 Leader 狀態。當服務器處于該狀態時，它會認為當前集群中沒有 Leader，因此需要進入 Leader 選舉狀態。
2、FOLLOWING：跟隨者狀態。表明當前服務器角色是 Follower。
3、LEADING：領導者狀態。表明當前服務器角色是 Leader。
4、OBSERVING：觀察者狀態。表明當前服務器角色是 Observer。
15、數據同步
16、zookeeper是如何保證事務的順序一致性的？
17、分布式集群中為什么會有Master？
18、zk節點宕機如何處理？
19、zookeeper負載均衡和nginx負載均衡區別
zk 的負載均衡是可以調控，nginx 只是能調權重，其他需要可控的都需要自己寫插件；但是 nginx 的吞吐量比 zk 大很多，應該說按業務選擇用哪種方式。
20、Zookeeper有哪幾種幾種部署模式？
部署模式：單機模式、偽集群模式、集群模式。
21、集群最少要幾臺機器，集群規則是怎樣的?
集群規則為 2N+1 臺，N>0，即 3 臺。
22、集群支持動態添加機器嗎？
其實就是水平擴容了，Zookeeper 在這方面不太好。兩種方式：
全部重啟：關閉所有 Zookeeper 服務，修改配置之后啟動。不影響之前客戶端的會話。
逐個重啟：在過半存活即可用的原則下，一臺機器重啟不影響整個集群對外提供服務。這是比較常用的方式。
3.5 版本開始支持動態擴容
23、Zookeeper對節點的watch監聽通知是永久的嗎？為什么不是永久的?
24、Zookeeper的java客戶端都有哪些？
java 客戶端：zk 自帶的 zkclient 及 Apache 開源的 Curator。
25、chubby是什么，和zookeeper比你怎么看？
chubby 是 google 的，完全實現 paxos 算法，不開源。zookeeper 是 chubby的開源實現，使用 zab 協議，paxos 算法的變種。
26、說幾個zookeeper常用的命令。
常用命令：ls get set create delete 等。
27、ZAB和Paxos算法的聯系與區別？
28、Zookeeper的典型應用場景
