概述

zookeeper的內存模型：

1. zk的數據存在內存當中（高性能），但是同時記錄操作日志+內存快照（二進制），持久化。（類似于Redis)
2. 狀態機+命令日志：內存中保存數據的最終狀態，命令日志中保存所有的操作過程，內存快照中保存某一時間節點的狀態機中的數據。

zookeeper集群的高性能：

1. 內存讀取數據
2. 所有Node直接response 讀請求，不需要走Master
3. 集群有Obeserver角色，擴展了讀的性能，又不影響投票和寫的性能（不參與選舉投票和ack proposal)

Zk的寫機制

所有的寫的請求，轉發給Leader，Leader采取兩階段提交的方式。

1. 本地生成自增的zxid，生成Proposal日志（持久化)
2. 廣播所有的Follower，并且有單獨的線程統計 Ack Proposal的數量
3. Proposal ack過半之后，廣播Commit，并且把這個request丟到各自的CommitProcessor里面處理
4. Master commit日志，更新lastCommitZxid，apply到內存樹中，Ack client操作成功

這里和Raft系統不同，Raft是master先commit，再ack 客戶，最后在下一個心跳消息里面通知所有小弟們commit

zk的讀機制

• Client直接和Zk的節點直連，如果是讀的請求，那么Node可以直接response，不需要走Master，保障了基于內存的快速讀取
• zk集群不能保證讀取到的數據是最新的，但是可以保證讀取到的數據，都是過半節點ACK確認的數據
• zk的讀取本來就沒有鎖的概念，一個消息還在寫，是讀取不到的，不像Hashtable。即使Master完成了寫的操作，如果Follower沒有Sync數據的話，也是讀取不到最新的數據的
• Zk直接兩種模式：默認模式（CP模式 選舉時停止讀寫請求）、Readonlymode模式（AP模式 選舉時停止寫請求，但是可以讀）

zk的角色

• LOOKING：進入leader選舉狀態
• FOLLOWING：leader選舉結束，進入follower狀態
• LEADING：leader選舉結束，進入leader狀態
• OBSERVING：處于觀察者狀態
  Observers和follower非常類似，observer的優點

1. 可以靈活的擴展zk集群，新增和減少observer不會觸發重新選舉
2. 大幅提升讀取的速度的同時，不會降低寫的速度
3. 一定程度上提升容災率，因為Observer的宕機不會影響集群繼續服務

選舉過程

和Raft算法相比，有點過度設計了，解決的是一個標準的拜占庭問題，不僅僅可以處理節點故障問題，還可以防止節點作弊。代價是消息交互的次數大大增加。
每個Node都在統計leader獲取的投票數，只有Node統計有新leader產生時，才會從Looking狀態，切換成Following狀態，而不是收到Leader的消息，就進入Following狀態。

1. Zk所有Node啟動時都有一個獨立的線程，不停的check自己當前的Role
2. 啟動剛啟動時、Follower 超時仍未收到心跳、Leader不能收到過半心跳恢復時，節點都會進入Looking狀態
3. 每個節點可以多次投票，每次投票都會廣播出去，一輪投票必定有一個leader產生，數據最新的節點肯定會成為leader，server id 越大，成為leader的概率也越高。

zk 一致性保證

1. 只有超過半數節點Ack了的事務操作，才會被commit，才會最終響應到客戶端。所以響應了客戶端的操作，不管leader是否掛了，新leader中肯定存了這個日志，否則選舉中不會獲勝。

2. 未完成半數Ack的事務操作，leader掛了，新leader可能保存這個日志，也可能沒有保存這個日志。

• 如果新leader沒有這個事務操作的日志，依賴客戶端的超時重試機制，來完成這個proposal，客戶端會發起重試。
• 如果新leader有這個uncommitted的事務操作日志，則會替代老leader繼續完成這個操作

zk 事務操作有序性

1. zk只能保證寫操作的有序性，而不能保證讀寫的有序性，比如Client先發起一個寫操作，再迅速發起一個讀取操作，并不能保證讀取的最新的數據。
2. zk通過自增的zxid的編號，在前期proposal和持久化的時候，并不需要嚴格有序，提升寫的性能，但是在commit的時候，通過鎖和有序FIFO隊列，保證嚴格的有序commit，apply到內存樹中。