這樣學習ZooKeeper離大廠所需技能要求還遠嗎

概述

定義

Apache ZooKeeper是一種用於構建分佈式應用的高性能、高度可靠、開源的分佈式協調服務，提供如配置信息維護、命名、分佈式同步、組服務等功能，可以實現如分佈式共識、組管理、領導選舉和到場協議；同時也是Google的Chubby一個Java語言版的開源實現。 最新版本3.7.0

ZooKeeper翻譯為中文則為動物園管理員，而眾所周知ZooKeeper是大數據生態下的重要組件,是大數據生態的基石之一，而我們也知道大部分大數據生態下組件是以動物命名並作為其Logo，比如Hive、Hbase、Flink等，所以ZooKeeper命名就更加生動貼切。官網客戶端API支持語言有Java和C，而我們從事Java技術棧的開發人員更多使用的是Apache Curator，由Netflix公司開源的一套ZooKeeper的客戶端框架，為開發人員屏蔽底層細節的開發工作如連接重連、反覆註冊Watcher和NodeExistsException異常，也封裝了一些高級特性如分佈式鎖、Cache事件監聽、選舉、分佈式Barrier等，可謂是ZooKeeper開發使用的利器。

應用場景

  • 命名服務

    • 依賴Zookeeper可以生成全局唯一的節點ID，來對分佈式系統中的資源進行管理。

  • 分佈式協調

    • 這是Zookeeper的核心使用了，利用Watch的監聽機制，一個系統的某個節點狀態發生改變，另外系統可以得到通知。

  • 集群管理

    • 分佈式集群中狀態的監控和管理，使用Zookeeper來存儲。

  • 分佈式鎖

    • 利用Zookeeper創建臨時順序節點的特性。
      • 保持獨佔：每個znode都可以看作一把鎖，在createZnode的時候，每個客戶端都去創建/distribute_lock,最終創建成功的那個客戶端就擁有了這把鎖，用完之後刪除/distribute_lock即可。
      • 控制時序：在/distribute_lock下面創建臨時順序節點，編號最小的擁有這把鎖，用完刪除。

  • 註冊中心

    • 擔任服務生產者和服務消費者的註冊中心，服務生產者將自己提供的服務註冊到Zookeeper中心，服務的消費者在進行服務調用的時候先到Zookeeper中查找服務，獲取到服務生產者的詳細信息之後，再去調用服務生產者的內容與數據。

      image-20211101141931634

  • 數據發佈訂閱

    • 常見的場景是配置中心，發佈者把數據發佈到 ZooKeeper 的一個或一系列的節點上，供訂閱者進行數據訂閱，達到動態獲取數據的目的。採用的是推拉結合的方式：
      • 推: 服務端會推給註冊了監控節點的客戶端 Wathcer 事件通知。
      • 拉: 客戶端獲得通知後，然後主動到服務端拉取最新的數據。

  • 分佈式隊列

    • 同步隊列：當一個隊列的所有成員都聚集時，這個隊列才可用；只需要在約定目錄下創建一個Watcher監聽，當達到指定數量時，就觸發Watcher通知機制。
    • FIFO隊列：與分佈式鎖差不多，入隊時有編號，出隊時按編號依次出隊。

  • 負載均衡、選主等

集群角色

  • leader角色
    • 事務請求的唯一調度和處理者，保證集群事務處理的順序性。
    • 集群內部各服務的調度者。
    • 處理所有的事務請求（寫請求），也可以處理讀請求，集群中只能有一個Leader，發起投票。
  • Follower角色
    • 處理客戶端的非事務請求，轉發事務請求給Leader服務器。
    • 參與事務請求Proposal的投票。
    • 參與Leader選舉投票。
    • 只處理讀請求，同時作為 Leader的候選節點，即如果Leader宕機，Follower節點要參與到新的Leader選舉中，有可能成為新的Leader節點。
  • Observer角色
    • 處理客戶端的非事務請求，轉發事務請求給Leader服務器。
    • 不參與任何形式的投票選舉。
    • 只能處理讀請求。

集群安裝

ZooKeeper官方下載地址 //zookeeper.apache.org/releases.html

我們下載二進制包即可，官方也同時提供源碼文件。

#單機版使用比較簡單，下載解壓、執行啟動腳本文件就完成了。zookeeper重要就是分佈式和高可靠性，如果自己都是單點那就說不過去了，索引我們這裡進行集群部署,準備三台虛擬機，使用xshell批量執行所有窗口的命令，可以提高部署效率，每台虛擬機先安裝jdk環境，這個已準備好，然後創建目錄下載zookeeper的二進制文件
wget //dlcdn.apache.org/zookeeper/zookeeper-3.7.0/apache-zookeeper-3.7.0-bin.tar.gz

image-20211029154101351

#解壓文件
tar -xvf apache-zookeeper-3.7.0-bin.tar.gz
#進入zookeeper根目錄
cd apache-zookeeper-3.7.0-bin/
#創建數據目錄和日誌目錄
mkdir data log
#進入配置文件
cd conf/
#重命名配置文件
mv zoo_sample.cfg zoo.cfg
#修改配置文件的內容為如下：
vim zoo.cfg

# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just 
# example sakes.
#存放數據文件
dataDir=/home/commons/apache-zookeeper-3.7.0-bin/data
#存放日誌文件
dataLogDir=/home/commons/apache-zookeeper-3.7.0-bin/log
# the port at which the clients will connect
clientPort=2181
#zookeeper cluster，2888為選舉端口，3888為心跳端口
server.1=192.168.50.34:2888:3888
server.2=192.168.50.35:2888:3888
server.3=192.168.50.36:2888:3888

#在我們配置的dataDir指定的目錄下面，創建一個myid文件，裏面內容為一個數字，用來標識當前主機，這個也是zookeeper用來領導選取算法輸入參數之一，conf/zoo.cfg文件中配置的server.X中X為什麼數字，則myid文件中就輸入這個數字：分別在三台上執行各自對應myid。
echo "1" >/home/commons/apache-zookeeper-3.7.0-bin/data/myid
echo "2" >/home/commons/apache-zookeeper-3.7.0-bin/data/myid
echo "3" >/home/commons/apache-zookeeper-3.7.0-bin/data/myid
#進入bin文件夾下執行啟動腳本
./zkServer.sh start
#通過jps或者ps查看zookeeper進程情況
ps -ef |grep zookeeper
#查看當前節點的狀態，從下面的結果得出36是集群的leader,另外兩個節點是follower
./zkServer.sh status

image-20211029162611668

image-20211029162854094

#通過客戶端腳本，可以在任何一個結點上建立到集群的連接進而操作整個ZooKeeper集群
./zkCli.sh -server 192.168.50.34:2181
#創建目錄
create /itxs "hello zookeeper"
#查看目錄，當我們連接到集群其他節點如35或36上再次查看節點的數據也是相同的，也即是zookeeper實現集群內部的數據同步
get /itxs

image-20211029164127497

image-20211029164312329

還可以使用zookeeper-dev-ZooInspector.jar可視化客戶端工具，搜索名稱下載即可

image-20211101172602735

數據節點

#查看節點詳細數據
stat /temp
#節點詳細說明
1）czxid-創建節點的事務zxid
  每次修改ZooKeeper狀態都會收到一個zxid形式的時間戳，也就是ZooKeeper事務ID。
  事務ID是ZooKeeper中所有修改總的次序。每個修改都有唯一的zxid，如果zxid1小於zxid2，那麼zxid1在zxid2之前發生。
2）ctime - znode被創建的毫秒數(從1970年開始)
3）mzxid - znode最後更新的事務zxid
4）mtime - znode最後修改的毫秒數(從1970年開始)
5）pZxid-znode最後更新的子節點zxid
6）cversion - znode子節點變化號，znode子節點修改次數
7）dataversion - znode數據變化號
8）aclVersion - znode訪問控制列表的變化號
9）ephemeralOwner- 如果是臨時節點，這個是znode擁有者的session id。如果不是臨時節點則是0。
10）dataLength- znode的數據長度
11）numChildren - znode子節點數量

image-20211101181054404

在 Zookeeper 中，可以說 Zookeeper 中的所有存儲的數據是由 znode 組成的，節點也稱為 znode，並以 key/value 形式存儲數據。整體結構類似於 linux 文件系統的模式以樹形結構存儲。其中根路徑以 / 開頭。通過get命令可以獲取如下信息

image-20211101162600618

節點類型

ZooKeeper支持7種znode類型，千萬不要再說只有4種了

  • PERSISTENT（持久化目錄節點）
    • 客戶端與zookeeper斷開連接後，該節點依舊存在，只要不手動刪除該節點，他將永遠存在，默認類型。
  • PERSISTENT_SEQUENTIAL（持久化順序目錄節點）
    • 客戶端與zookeeper斷開連接後，該節點依舊存在，Zookeeper還會給該節點名稱進行順序編號，單調遞增。
  • EPHEMERAL（臨時目錄節點）
    • 客戶端與zookeeper斷開連接後，該節點被刪除。
  • EPHEMERAL_SEQUENTIAL（臨時順序目錄節點）
    • 客戶端與zookeeper斷開連接後，該節點被刪除，Zookeeper還會給該節點名稱進行順序編號，單調遞增。
  • Container （容器節點）
    • zookeeper 3.5.3 版本新增的，容器節點主要用來容納位元組點，如果沒有給其創建子節點，容器節點表現和持久化節點一樣，如果給容器節點創建了子節點，後續又把子節點清空，容器節點也會被zookeeper刪除。特殊用途對於諸如leader、lock等非常有用，服務端會定期掃描這些節點，當該節點下面沒有子節點時（或其他條件時）服務端會自動刪除節點。
  • PERSISTENT_WITH_TTL（持久化TTL節點）
    • zookeeper的擴展類型，如果znode在給定的TTL內沒有被修改，它將在沒有子節點時被刪除。需要額外配置才能啟用，必須在zookeeper的bin/zkService.sh中的啟動zookeeper的java環境中設置環境變量zookeeper.extendedTypesEnabled=true（具體做法在下邊），基本和容器相同，當超過 TTL 時間節點下面都沒有再創建子節點時會被刪除，但是當創建子節點會重置該超時時間。
  • PERSISTENT_SEQUENTIAL_WITH_TTL（持久化順序TTL節點）
    • 和TTL節點類似，只是多了順序性，該特性是由父節點維護的一個自增整型數字。

核心功能

ZooKeeper主要提供文件系統、通知機制和集群管理核心功能

  • 文件系統

    • zookeeper集群是有一個叫做命名節點空間的概念，其中節點就是znode,在zookeeper的文件系統中有兩種節點，一是數據節點，二是目錄節點，但是只有數據節點能存放數據。

    image-20211101141638735

    • zookeeper集群為了維護高吞吐和低延遲的特性，就維護了這樣樹狀的目錄結構，而且數據節點的存儲量不能太大，最多為1M。

  • 通知機制

    • 當某個client監聽某個節點時，當該節點發生變化時（有可能是增加子節點，或者節點值變了等），zk就會通知監聽該節點的客戶端來處理。

  • 集群管理

    • zk本身是一個集群結構，有一個leader節點，負責寫請求，多個follower負責響應讀請求。並且在leader節點故障時，會自動根據選舉機制從剩下的follower中選出新的leader。

架構原理

分佈式基礎理論

ZooKeeper可以說是分佈式理論中最典型的中間件教科書，為了更好理解分佈式領域技術，我們需要先了解CAP、BASE這兩個分佈式基礎理論，也是高頻出現在大廠或名企的面試中特別是大中型的互聯網企業。

CAP理論

  • 一致性（Consistency）：數據在多個副本之間是否能夠保持一致的特性。（當一個系統在一致狀態下更新後，應保持系統中所有數據仍處於一致的狀態）
  • 可用性（Availability）：系統提供的服務必須一直處於可用狀態，對每一個操作的請求必須在有限時間內返回結果。好的可用性主要是指系統能夠很好的為用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況
  • 分區容錯性（Tolerance of network Partition）：分佈式系統在遇到網絡分區故障時，仍然需要保證對外提供一致性和可用性的服務，除非整個網絡都發生故障；比如節點1和節點3出現故障，但是依然能夠很好地對外提供服務。
  • CAP理論是指在一個分佈式系統中最多只能同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項

image-20211029170952632

  • 對於分佈式系統來說，P(分區容忍性)是基本要求必須要保證的，否則就失去了價值，所以剩下要麼CP組合，要麼是AP組合。因此設計分佈式數據系統，就是在一致性和可用性之間取一個平衡，對於大多數場景並不需要強一致性，因此犧牲一致性而換取高可用性，這個也是目前多數分佈式數據庫產品的方向。但這裡很多人不要產生了誤區，犧牲一致性並不是不要一致性，而是在可用性前提下儘可能提高數據一致性，而數據一致性從強到弱可以分為強一致性、最終一致性、弱一致性。
    • 強一致性
      • 對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到，這是強一致性。比如小林更新values0到values1，那麼小李讀取值時也應該是values1。
    • 弱一致性
      • 如果能容忍後續的部分或者全部訪問不到，則是弱一致性。比如小林更新values0到values1，可以容忍那麼小李讀取值時是values0。
    • 最終一致性
      • 如果經過一段時間後要求能訪問到更新後的數據，則是最終一致性。比如小林更新values0到values1，可以使得小李在一段時間之後讀取值時是values1。

BASE理論

  • BASE包含 Basically Available(基本可用)、Soft state(軟狀態)和 Eventually consistent (最終一致性)這三個短語的縮寫。

[外鏈圖片轉存中…(img-ppG13Ys0-1640099320347)]

  • BASE理論是是eBay 的架構師 Dan Pritchett 提出,對CAP中AP的一個擴展，通過犧牲強一致性來獲得可用性，當出現故障允許部分不可用但要保證核心功能可用，允許數據在一段時間內是不一致的，但最終達到一致狀態。滿足BASE理論的事務，我們稱之為「柔性事務」。

    • Basically Available 基本可用：分佈式系統在出現故障時，允許損失部分可用功能，保證核心功能可用。可以體現在時間上的損失和功能上的損失。如部分用戶雙十一淘寶頁面卡頓或降級處理。
    • Soft state 軟狀態：由於不要求強一致性，所以BASE允許系統中存在中間狀態（也叫軟狀態），即系統的不同節點的數據副本之間的數據同步過程存在延遲，這個狀態不影響系統可用性，如訂單的”支付中”、「數據同步中」等狀態，待數據最終一致後狀態改為「成功」狀態。

Zab協議

zookeeper非常核心就是原子廣播保證各個server之間的同步，而實現這個機制就是Zab協議（全稱 Zookeeper Atomic Broadcast），Zab協議是為分佈式協調服務Zookeeper專門設計的一種支持崩潰恢復的原子廣播協議；ZAB協議包括兩種基本的模式：崩潰恢復和消息廣播：

  • 當整個zookeeper集群剛剛啟動或者Leader服務器宕機、重啟或者網絡故障導致不存在過半的服務器與Leader服務器保持正常通信時，所有進程（服務器）進入崩潰恢復模式，首先選舉產生新的Leader服務器，然後集群中Follower服務器開始與新的Leader服務器進行數據同步。
  • 當集群中超過半數機器與該Leader服務器完成數據同步之後，退出恢復模式進入消息廣播模式，Leader服務器開始接收客戶端的事務請求生成事物提案來進行事務請求處理。

Zab 協議的原理可細分為四個階段：選舉（Leader Election）、發現（Discovery）、同步（Synchronization）和廣播（Broadcast）

  • Leader election(選舉階段)
    • 節點在一開始都處於選舉階段，只要有一個節點得到超過半數節點的票數，它就可以當選准 Leader。
  • Discovery(發現階段)
    • 在這個階段，Followers跟准Leader進行通信，同步Followers最近接收的事務提議。
  • Synchronization(同步階段)
    • 同步階段主要是利用Leader前一階段獲得的最新提議歷史，同步集群中所有的副本。同步完成之後准Leader才會成為真正的Leader。
  • Broadcast(廣播階段)
    • 到了這個階段，Zookeeper集群才能正式對外提供事務服務，並且Leader 可以進行消息廣播。同時如果有新的節點加入，還需要對新節點進行同步。

分佈式一致性算法和共識機制？

Paxos 分佈式一致性算法，強一致算法，也是一種分佈式共識算法，基於提案及核心理念也都是基於多數派原則，大部分也是基於2pc兩階段提交（投票-執行）、3pc三階段提（交投票-預提交-執行）的演變，上面說的Zab與Paxos 具有一些相似之處，而從設計上看ZAB協議和 Raft本質 更是比較類似。Paxos 協議有三大分支包括basic、multi、fast，都是比較難以理解，而Raft協議則是Paxos簡化版或者變種版，很多開源中間件如Nacos、Etcd、Redis哨兵集群、Consul、Tidb都有Raft協議的實現。Raft原理中主要涉及兩大活動選主和日誌複製：

  • Raft中有三個角色leader follower candidate，所有節點默認為跟隨者，follower可以成為候選者，發起投票，過半就成為leader，之後領導者就開始向其關注者發送條目信息，這些消息是以心跳超時指定間隔發送，然後關注者回復每個附加條目信息，所有更改都通過leader。
  • Raft選舉超時follower等待成為candidate的超時時間，Term任期編號自增。超時時鐘做隨機，新的leader同步所有數據信息包括任期，每個節點有一個倒計時器（election timeout）,時間隨機在150~300ms,當收到選舉請求和leader的心跳重置,發送term編號，每個編號跟隨者發送一次不再回複發送，也即是每個任期只投票一次，重票則重新進行新任期選舉；網絡分區後，任期較低的一邊同步任期高的數據。

Watch機制

客戶端註冊監聽他關心的目錄節點，當目錄節點發生變化（數據改變、被刪除、子目錄節點增加刪除）時，Zookeeper會通知客戶端。client端會對某個znode建立一個watcher事件，當該znode發生變化時，zk會主動通知watch這個znode的client，然後client根據znode的變化來做出業務上的改變等。首先客戶端會向服務端註冊一個Watcher監聽，當服務端的某些指令觸發了這個Watcher的話，服務端就會向客戶端返回一個消息通知，客戶端接收到消息之後便可以做出業務上的改變，主要流程如下：

  • 客戶端註冊Watcher：客戶端先向Zookeeper服務端成功註冊想要監聽的節點狀態。
    • 首先會訪問getData()/getChildren()/exist()三個API，傳入Watcher對象。
    • 標記請求request,將Watcher封裝成WatcherRegistration對象。
    • 再封裝成Packet對象，服務端發送request。
    • 接收到服務端的request請求之後，將Watcher註冊到zkWatcherManager中進行管理。
    • 將結果返回給客戶端，註冊成功。
  • 服務端觸發Watcher：同時客戶端本地會存儲該監聽器相關的信息在WatchManager中。
    • 首先根據客戶端的請求判斷是否需要註冊Watcher。
    • 比如服務端觸發了setData()/delete()/create()方法，會觸發一個叫做NodeDataChanged（）的事件。
    • 服務端會將觸發的事件類型、節點的路徑封裝成一個叫做WatchedEvent的對象。
    • 再向zkWatcherManager中的WatcherTable中根據節點路徑查找。若找不到，說明客戶端沒有註冊過Watche，若找到，將Watcher從WatcherTable中刪除（說明Watcher監聽是一次性的）。
    • 調用process方法觸發Watcher,主要是通過Servercnxn的TCP連接來通知客戶端。
  • 客戶端回調Watcher：當Zookeeper服務端監聽的數據狀態發生變化時，Zookeeper就會主動通知發送相應事件信息給相關會話客戶端，從WatherManager中取出對應Wather對象執行回調邏輯。
    • 客戶端有個SendThread來接收Watcher通知的線程，接收的通知之後會交由EventThread線程處理。
    • 客戶端的Watcher監聽也是一次性的，一旦觸發也會被刪除。

ZookeeperServer工作狀態

Zookeeper服務器具有四種狀態，分別是LOOKING、FOLLOWING、LEADING、OBSERVING。

  • LOOKING：尋找Leader狀態。當服務器處於該狀態時，它會認為當前集群中沒有Leader，因此需要進入Leader選舉狀態。
  • FOLLOWING：跟隨者狀態。表明當前服務器角色是Follower。
  • LEADING：領導者狀態。表明當前服務器角色是Leader。
  • OBSERVING：觀察者狀態。表明當前服務器角色是Observer。

ZooKeeper是如何保證事務的順序一致性的？

  • zookeeper採用全局遞增的事務id(zxid)來保證事務的順序一致性的。
  • 所有的提議在被提出的都會攜帶這個zxid,zxid是一個64位的數字；高32位是個epoch（時期，紀元，世，新時代）值，表示leader選舉周期，每進行一次leader選舉，該數字就會+1；後32位用來表示遞增計數,當產生新的提議時，會依據數據庫的兩階段提交過程，首先會像其它節點發送執行請求，如果超過半數以上的機器正確執行，那麼該事務就可以被執行。

Zookeeper的架構與集群規則?

image-20211101153225467

一個領導者和多個跟隨者，超過半數過半機制，每個節點有一份全量數據，更新請求轉發且按順序依次執行，數據更新原子性原則，實時性（客戶端可以讀取最新數據，有序性是zookeeper中非常重要的一個特性，所有的更新都是全局有序的，每個更新都有一個唯一的zxid，而讀請求只會相對於更新有序，也就是讀請求的返回結果中會帶有這個zookeeper最新的zxid；Zookeeper是可以集群複製的，集群間通過Zab協議（Zookeeper Atomic Broadcast）來保持數據的一致性。

集群機器台數規則為2N+1台，N>0，也即是集群數量建議為基數台，最小集群為3台，最低生產環境一般建議三個機房，每個機房分別為3、2、2。由於設計和實現Zookeeper集群也不會出現腦裂問題(當出現網絡分區割斷後分佈式現象問題)。

  • 首先我們知道zookeeper選舉的規則可用節點數量 > 總節點數量/2，集群中只要有過半的機器是正常工作的，那麼整個集群對外就是可用的。
  • 比如標記一個寫是否成功是要在超過一半節點發送寫請求成功時才認為有效。同樣，Zookeeper選擇領導者節點也是在超過一半節點同意時才有效。最後，Zookeeper是否正常是要根據是否超過一半的節點正常才算正常。
  • 2n和2n-1的容忍度是一樣的，都是n-1，所以不需要增加一個不必要的zookeeper節點。
  • zookeeper的選舉策略也是需要半數以上的節點同意才能當選leader，如果是偶數節點可能導致票數相同的情況。

怎麼做leader選舉？

當Zookeeper集群在啟動時，或者當leader節點出現網絡中斷、崩潰等情況時，Zookeeper就會進入恢復模式並選舉產生新的 Leader。

  • SID: ServerID,用來唯一標識一台Zookeeper集群中的機器，全局唯一，serverid也即是myid，在配置文件中指定。
  • ZXID：事務ID，用來唯一標識一次服務器狀態的變更，在同一時刻中集群內部每一台機器的ZXID未必完全一致。

大體過程：Leader收到消息請求先生成全局自增zxid,然後為每個follower創建FIFO隊列保證有序，將消息作為提案發給所有follower, follower收到提案先寫磁盤然後回復ack給leader,當leader收到半數以上follower的ack後向follower發送commit請求,同時本地執行存儲和業務響應結果，follower收到後commit提交更新內存，執行投票不需要觀察者的ack但觀察者必須同步leader數據。

  • 第一步:每個Server發出一個投票提議，並且先投自己。
  • 第二步:接收來自各個服務器的投票，節點進行投票。
  • 第三步:PK選票並更新選票(pk進行改票，集合zxid，serverid根據數據最近原則)，存內存、磁盤。
  • 第四步:統計所有投票，判斷是否有過半機器接收到相同的投票信息；核心是集合2pc兩階段提交和過半機制，並通過原子廣播保證數據同步。
  • 第五步:改變服務器狀態，選主完成並且有一半節點和leadder數據同步完成退出恢復模式，一旦確定Leader，每個服務器更新自己的狀態。

Zookeeper寫數據流程

image-20211101155510443

  • Client向Zookeeper的Server1上寫數據,發送一個寫請求。
  • 如果Server1不是Leader,那麼Server1會把接收到的請求進一步轉發給Leader,因為每個Zookeeper集群裏面有一個是Leader。
  • Leader會將寫請求廣播給各個Server,各個Server寫成功後會通知Leader。
  • 當Leader收到大多數Server數據寫成功了,就說明數據寫成功了.如果這裡有五個節點的話,只要有三個節點數據寫成功了.那麼就認為數據寫成功了。
  • 寫成功以後,Leader就會告訴Server1數據寫成功了。
  • Server1會進一步通知Client數據寫成功了,這時就認為整個寫操作成功。

zookeeper數據同步實現方式

zookeeper實現數據同步有4種方式，即直接差異化同步、先回滾再差異化同步、僅回滾同步、全量同步；首先先從learner(follower和observer節點的統稱)節點獲取最後一次操作數據的zxid,再從leader節點中獲取最小的minZxid和最大的maxZxid。

  • 如果minZxid<zxid<maxZxid –>採用直接差異化同步
  • 如果leader服務器發現learner服務器包含了自己不存在的數據，那麼learner服務器需要回滾到leader包含的數據然後在差異化處理 –>先回滾再差異化同步
  • 如果zxid>maxZxid –>僅回滾同步即可
  • 如果zxid<minZxid –>全量同步

權限控制列表ACL

zookeeper的權限控制列表包含三個部分

  • 授權模式
    • IP:授權模式精確到IP粒度。
    • Digest:相當於username:password，最常用的一種授權模式。
    • World：相當於最特殊的Digest模式world:everyone,最開放的一種授權模式。
    • Super：超級用戶。
  • 授權對象：被授予權限的用戶例如某個IP
  • 權限
    • Create:創建。
    • Delete：刪除。
    • Read：讀。
    • Write：寫。
    • Admin：管理
Tags:

VirMach 便宜 VPS

QNews

QNews