幾個重要的點：

①leader肯定會掛

②服務不可用

③不可靠的集群

④in fact，zk集群極其高可用

⑤可以快速恢復一個leader

zookeeper中有兩種運行狀態：

①可用狀態

②不可用狀態

③不可用狀態恢復到可用狀態時間越短越好

zookeeper的主從模型，只有一個主節點，而且只有主節點負責寫，從節點的寫操作必須發給主節點來完成。

①順序一致性：客戶端發過來的更新請求將按順序執行。

②原子性：更新要么都成功，要么都失敗。沒有其他狀態。只有leader主節點寫成功之后再復制給其他follower從節點。

③單系統映像：無論客戶端連接到哪個zk節點，客戶端都將看到相同的服務視圖。

④可靠性：一旦應用進行了更新，它將從那時起持續到客戶端覆蓋更新。因為進行了持久化才能這么搞。

⑤實時性：系統的客戶視圖保證在特定時間范圍內是最新的。

zookeeper選擇新領導者的時間不到200毫秒

zookeeper很快：它在“讀取主導”的工作負載中特別快，并且在讀取比寫入更常見的情況下表現更加

（redis單節點一秒鐘大概能hold住10w左右的并發）

如下圖所述，zk集群只有3個節點時能hold住8w左右，13個節點能hold住14w左右請求。

zookeeper是一個目錄樹結構，zk中任意節點均可存放數據，但存的數據量比較小，只有1M。

這點有別于文件系統，因為文件夾是不能存放數據的，只能存放文件夾和文件。

所以，不要把zookeeper當做數據庫用。為了保證快，必須要保證所有節點傳輸數據時數據體量越小越好。不要讓zookeeper寫的比例過大，讀多寫少，性能才更優。

zookeeper中的節點：

①持久節點

②臨時節點

每個客戶端連接到zk節點時會產生一個session來代替該客戶端，就是一次會話，連接斷開時會話銷毀。?

?

總結

以上是生活随笔為你收集整理的zookeeper宏观认识的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。