ZooKeeper作爲J2EE體系內一款高性能協調器，廣泛用於SOA等場景，需要簡單瞭解ZK的一些關鍵特性
- 分佈式系統
- CAP原則，不能同時滿足，如何取捨
- 一致性（Consistence) （等同於所有節點訪問同一份最新的數據副本）
- 可用性（Availability）（每次請求都能獲取到非錯的響應——但是不保證獲取的數據爲最新數據）
- 分區容錯性（Network partitioning）（以實際效果而言，分區相當於對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味着發生了分區的情況，必須就當前操作在C和A之間做出選擇。）
- 一致性原則，分佈一致性算法
- 2PC/3PC算法，改進，優缺點
- Paxos協議
- Paxos 裏面的四個角色:Proposer,Acceptor,Client,Learner
- Paxos 如何避免2PC的腦裂問題
- Paxos 的一次決議過程，兩個階段
- Paxos 兩個決議階段存在的問題，高併發情況下第一個階段通過的決議會被拒絕
ZooKeeper相關
- 基於Paxos拓展的ZAB(Zookeeper Atomic Broadcast)協議
- Leader選舉
- Atomic Broadcast
- Leader角色爲了解決paxos協議的效率問題
- ZooKeeper實現的主要功能
- 順序一致性
- 原子性
- 單一視圖
- 可靠性
- 實時性
- ZK寫入過程描述
- ZK的Watch機制實現原理
- ZK常見應用
- 分佈式鎖，驚羣效應，實時數據不一致如何處理
- ZkNode報文大小管理，1M以下
- 跨客戶端視圖的併發一致性:ZooKeeper並不保證在某時刻，兩個不同的客戶端具有一致的數據視圖。因爲網絡延遲的原因，一個客戶端可能在另一個客戶端得到修改通知之前進行更新。假定有兩個客戶端A和B。如果客戶端A將一個節點/a的值從0修改爲1，然後通知客戶端B讀取/a，客戶端B讀取到的值可能還是0，這取決於它連接到了哪個服務器。如果客戶端A和B讀取到相同的值很重要，那麼客戶端B應該在執行讀取之前調用sync()方法。
主備切換對於未提交的歷史數據如何處理