分佈式技術 -- 二、ZooKeeper特色以及數據結構

一、Zookeeper特色：

• Zookeeper：一個領導者(Leader) ，多個跟隨者(Follower) 組成的集羣。這與Redis的集羣概念同樣的，Redis是一主多從。
• 集羣中只要有半數以上（必須大於集羣數量的一半，等於一半也不行）節點存活，Zookeeper集羣就能正常服務。
• 全局數據一致性：每一個服務Server保存一份相同的數據副本，Client不管鏈接到哪一個Server服務，獲取到的數據都是一致的。
  • 每一個服務Server保存的數據副本很是小的，主要是一些服務的配置文件而已。
• 更新請求順序進行，來自同一個Client的更新請求按其發送順序依次執行。
  • 好比：一個Client前後發了三次請求分別是1請求、2請求、3請求，Zookeeper就依次按順序處理1請求、再處理2請求、最後3請求。
• 數據更新原子性，一次數據更新，要麼成功，要麼更新失敗。這和SQL的事務特色很類似。
• 實時性，在必定時間範圍內，Client能讀到最新數據。
  • 就是說集羣之間同步數據副本的時間很是之短，由於上面第三點說起每一個服務Server保存的數據副本的容量很是小。

 

二、Zookeeper的數據結構：

        與Linux系統的目錄結構同樣的（根目錄/子目錄/子目錄......），這裏就不詳細說了。Zookeeper中每一個節點被成爲ZNode，而且每一個ZNode默認是存儲1M的數據，這就是上述Zookeeper特色中爲什麼能實現數據實時性 以及 數據一致性的緣由。

 

三、Zookeeper的應用場景：

•     統一命名服務：便於識別。
•     統一配置管理：每一個服務保存的配置信息要求一致。作到每一個客戶端訪問到的哪一個服務的數據都是同樣的
•     統一集羣管理：實時監控每一個ZNode的數據信息狀態（是否有更新了）。
•     服務器節點動態上下線：一旦發現有服務掛了或者上線，Zookeeper會去通知客戶端有服務掛了或者上線。
•     軟負載均衡：讓新的請求服務分配交由訪問數量較少的服務器去處理。

 

我是楊展浩。這是個人第四篇博客。加油！！！