Zookeeper原理介紹

 

Zookeeper原理介紹

1、概述

    Zookeeper是一個工具,能夠實現集羣中的分佈式協調服務。服務器

    所謂的分佈式協調服務,就是在集羣的節點中進行可靠的消息傳遞,來協調集羣的工做。網絡

    Zookeeper之因此可以實現分佈式協調服務,靠的就是它可以保證分佈式數據一致性。數據結構

    所謂的分佈式數據一致性,指的就是能夠在集羣中保證數據傳遞的一致。負載均衡

    Zookeeper可以提供的分佈式協調服務包括:數據發佈訂閱、負載均衡、命名服務、分佈式協調/通知、集羣管理、分佈式鎖、分佈式隊列等功能分佈式

一、Zookeeper的特色

    Zookeeper工做在集羣中,對集羣提供分佈式協調服務,它提供的分佈式協調服務具備以下的特色:工具

1.順序一致性

    從同一個客戶端發起的事務請求,最終將會嚴格按照其發起順序被應用到zookeeper中oop

2.原子性

    全部事物請求的處理結果在整個集羣中全部機器上的應用狀況是一致的,即,要麼整個集羣中全部機器都成功應用了某一事務,要麼都沒有應用,必定不會出現集羣中部分機器應用了改事務,另一部分沒有應用的狀況。spa

3.單一視圖

    不管客戶端鏈接的是哪一個zookeeper服務器,其看到的服務端數據模型都是一致的。.net

4.可靠性

    一旦服務端成功的應用了一個事務,並完成對客戶端的響應,那麼該事務所引發的服務端狀態變動將會一直保留下來,除非有另外一個事務又對其進行了改變。server

5.實時性

    zookeeper並非一種強一致性,只能保證順序一致性和最終一致性,只能稱爲達到了僞實時性。

2、數據模型

    zookeeper中能夠保存數據,正是利用zookeeper能夠保存數據這一特色,咱們的集羣經過在zookeeper裏存取數據來進行消息的傳遞。

一、數據結構

    zookeeper中保存數據的結構很是相似於文件系統。都是由節點組成的樹形結構。不一樣的是文件系統是由文件夾和文件來組成的樹,而zookeeper中是由ZNODE來組成的樹。

    每個ZNODE裏均可以存放一段數據,ZNODE下還能夠掛載零個或多個子ZNODE節點,從而組成一個樹形結構。

二、數據模型分類

    節點有順序節點、普通節點、臨時節點和持久節點,四種交叉產生如下四種實際節點類型。

  順序節點 普通節點
臨時節點 順序臨時節點 普通臨時節點
持久節點 數序持久節點 普通持久節點

    順序節點:指定叫什麼,除了前綴是指定的名字外,在名字後會會自帶一個獨一無二自動增加的的編號。

    普通節點:指定叫什麼就叫什麼。

    臨時節點:一個客戶端鏈接建立的臨時節點,會在當客戶端會話結束時當即自動刪除。

    持久節點:建立出來後只要不刪除就不會消失,不管客戶端是否鏈接。

3、zookeeper原理

    zookeeper爲了保證可靠性,不能用一臺機器,而應該是一個集羣。

    爲了保證zookeeper集羣數據可以一致,必須有一個拍板說了算的人,這就是leader,其餘的是follower。某一時刻集羣裏只能有且僅有一個leader。leader能夠執行增刪改和查詢操做,而follower只能進行查詢操做。全部的更新操做都會被轉交給leader來處理,leader批准的任務,再發送給follower去執行來保證和leader的一致性。

    因爲網絡是不穩定的,爲了保證執行順序的一致,全部的任務都會被賦予一個惟一的順序的編號,必定是按照這個編號來執行任務,保證任務順序的一致性。

    那麼何時leader能夠認爲一個客戶端的請求能夠算是處理成功了呢?

    若是隻有leader或少數機器來承認這個任務,則leader和這些少許機器若是掛掉,則選出來的新的leader並不知道以前批准過的這個任務,最終會違反數據的可靠性。因此要求leader在批准一個任務以前應該保證集羣裏大部分的機器應該是知道這個提案的,這樣即便本身掛掉,根據過半贊成選出來的leader確定是知道這個提案的。而若是leader必定要等到全部follower都贊成才執行提案也很差,由於若是有一個機器掛掉,leader就沒法工做,也至關於單節點了,沒法保證集羣可靠性。因此,只要過半經過leader就能夠認爲一個提案經過。因此,leader在收到客戶端提交過來的任務後,會向集羣中全部的follower發送提案等待follower的投票,follower們收到這個提議後,會進行投票,贊成或者不一樣意,leader會回收follower的投票,一旦收到過半的投票表示贊成,則leader認爲這個提案經過,再發送命令要求全部的follower都進行這個提案中的任務。

    由於採用過半贊成機制,因此最極端的狀況下集羣中有過半的機器知道最新提案,而若是過半的機器掛掉,則剩下的機器可能不知道最新提案,則沒法保證新選出的leader知道最新提案,因此zookeeper中,集羣的及其至少要保證過半的存活才能才能正常工做。

    總結:

    zookeeper集羣使用了過半選舉投票機制,因此必須保證過半存活才能工做,zookeeper的集羣中的機器數量最好應該是奇數個,由於須要過半存活集羣才能工做,因此偶數個機器提供的集羣可靠性其實和偶數-1個機器提供的集羣可靠性是同樣的。

    leader選舉的問題:

    最開始集羣啓動時,會選擇最早達到過半條件的機器做爲leader。

    當leader掛掉後,會經過過半投票選出具備最高任務編號的機器成爲新的leader。若是有相同的任務編號,那麼在配置文件中,誰的serverid大誰爲leader。

    未完待續…………!

    上一篇:Zookeeper集羣的搭建

    下一篇:Hadoop簡介

相關文章
相關標籤/搜索