自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

史上最便捷搭建Zookeeper服務(wù)器的方法

運維 系統(tǒng)運維
ZooKeeper 便捷的使用方式、卓越的性能和良好的穩(wěn)定性,被廣泛地應(yīng)用于諸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系統(tǒng)中。

[[360822]]

 什么是 ZooKeeper

ZooKeeper 是 Apache 的一個頂級項目,為分布式應(yīng)用提供高效、高可用的分布式協(xié)調(diào)服務(wù),提供了諸如數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知和分布式鎖等分布式基礎(chǔ)服務(wù)。由于 ZooKeeper 便捷的使用方式、卓越的性能和良好的穩(wěn)定性,被廣泛地應(yīng)用于諸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系統(tǒng)中。

Zookeeper有三種運行模式:單機模式、偽集群模式和集群模式。

  •  單機模式:這種模式一般適用于開發(fā)測試環(huán)境,一方面我們沒有那么多機器資源,另外就是平時的開發(fā)調(diào)試并不需要極好的穩(wěn)定性。
  •  集群模式:一個 ZooKeeper 集群通常由一組機器組成,一般 3 臺以上就可以組成一個可用的 ZooKeeper 集群了。組成 ZooKeeper 集群的每臺機器都會在內(nèi)存中維護當(dāng)前的服務(wù)器狀態(tài),并且每臺機器之間都會互相保持通信。
  •  偽集群模式:這是一種特殊的集群模式,即集群的所有服務(wù)器都部署在一臺機器上。當(dāng)你手頭上有一臺比較好的機器,如果作為單機模式進行部署,就會浪費資源,這種情況下,ZooKeeper 允許你在一臺機器上通過啟動不同的端口來啟動多個 ZooKeeper 服務(wù)實例,以此來以集群的特性來對外服務(wù)。

ZooKeeper 的相關(guān)知識

Zookeeper中的角色:

  •  領(lǐng)導(dǎo)者(leader):負(fù)責(zé)進行投票的發(fā)起和決議,更新系統(tǒng)狀態(tài)。
  •  跟隨者(follower):用于接收客戶端請求并給客戶端返回結(jié)果,在選主過程中進行投票。
  •  觀察者(observer):可以接受客戶端連接,將寫請求轉(zhuǎn)發(fā)給 leader,但是observer 不參加投票的過程,只是為了擴展系統(tǒng),提高讀取的速度。圖片

Zookeeper 的數(shù)據(jù)模型

  •  層次化的目錄結(jié)構(gòu),命名符合常規(guī)文件系統(tǒng)規(guī)范,類似于 Linux。
  •  每個節(jié)點在 Zookeeper 中叫做 Znode,并且其有一個唯一的路徑標(biāo)識。
  •  節(jié)點 Znode 可以包含數(shù)據(jù)和子節(jié)點,但是 EPHEMERAL 類型的節(jié)點不能有子節(jié)點。
  •  Znode 中的數(shù)據(jù)可以有多個版本,比如某一個路徑下存有多個數(shù)據(jù)版本,那么查詢這個路徑下的數(shù)據(jù)就需要帶上版本。
  •  客戶端應(yīng)用可以在節(jié)點上設(shè)置監(jiān)視器。
  •  節(jié)點不支持部分讀寫,而是一次性完整讀寫。圖片

ZooKeeper 的節(jié)點特性

ZooKeeper節(jié)點是生命周期的,這取決于節(jié)點的類型。在 ZooKeeper 中,節(jié)點根據(jù)持續(xù)時間可以分為持久節(jié)點(PERSISTENT)、臨時節(jié)點(EPHEMERAL),根據(jù)是否有序可以分為順序節(jié)點(SEQUENTIAL)、和無序節(jié)點(默認(rèn)是無序的)。

持久節(jié)點一旦被創(chuàng)建,除非主動移除,不然一直會保存在 Zookeeper 中(不會因為創(chuàng)建該節(jié)點的客戶端的會話失效而消失)。

Zookeeper 的應(yīng)用場景

ZooKeeper 是一個高可用的分布式數(shù)據(jù)管理與系統(tǒng)協(xié)調(diào)框架?;趯?Paxos 算法的實現(xiàn),使該框架保證了分布式環(huán)境中數(shù)據(jù)的強一致性,也正是基于這樣的特性,使得 ZooKeeper 解決很多分布式問題。

值得注意的是,ZooKeeper 并非天生就是為這些應(yīng)用場景設(shè)計的,都是后來眾多開發(fā)者根據(jù)其框架的特性,利用其提供的一系列 API 接口(或者稱為原語集),摸索出來的典型使用方法。

數(shù)據(jù)發(fā)布與訂閱(配置中心)

發(fā)布與訂閱模型,即所謂的配置中心,顧名思義就是發(fā)布者將數(shù)據(jù)發(fā)布到 ZooKeeper 節(jié)點上,供訂閱者動態(tài)獲取數(shù)據(jù),實現(xiàn)配置信息的集中式管理和動態(tài)更新。例如全局的配置信息,服務(wù)式服務(wù)框架的服務(wù)地址列表等就非常適合使用。

應(yīng)用中用到的一些配置信息放到 ZooKeeper 上進行集中管理。這類場景通常是這樣:應(yīng)用在啟動的時候會主動來獲取一次配置,同時在節(jié)點上注冊一個 Watcher。這樣一來,以后每次配置有更新的時候,都會實時通知到訂閱的客戶端,從來達到獲取最新配置信息的目的。

分布式搜索服務(wù)中,索引的元信息和服務(wù)器集群機器的節(jié)點狀態(tài)存放在 ZooKeeper 的一些指定節(jié)點,供各個客戶端訂閱使用。

分布式日志收集系統(tǒng)

這個系統(tǒng)的核心工作是收集分布在不同機器的日志。收集器通常是按照應(yīng)用來分配收集任務(wù)單元,因此需要在 ZooKeeper 上創(chuàng)建一個以應(yīng)用名作為 path 的節(jié)點 P,并將這個應(yīng)用的所有機器 IP,以子節(jié)點的形式注冊到節(jié)點 P 上。這樣一來就能夠?qū)崿F(xiàn)機器變動的時候,能夠?qū)崟r通知到收集器調(diào)整任務(wù)分配。

系統(tǒng)中有些信息需要動態(tài)獲取,并且還會存在人工手動去修改這個信息的發(fā)問。通常是暴露出接口,例如 JMX 接口,來獲取一些運行時的信息。引入 ZooKeeper 之后,就不用自己實現(xiàn)一套方案了,只要將這些信息存放到指定的 ZooKeeper 節(jié)點上即可。

注意:在上面提到的應(yīng)用場景中,有個默認(rèn)前提——數(shù)據(jù)量很小,但是數(shù)據(jù)更新可能會比較快的場景。

負(fù)載均衡

這里說的負(fù)載均衡是指軟負(fù)載均衡。在分布式環(huán)境中,為了保證高可用性,通常同一個應(yīng)用或同一個服務(wù)的提供方都會部署多份,達到對等服務(wù)。而消費者就須要在這些對等的服務(wù)器中選擇一個來執(zhí)行相關(guān)的業(yè)務(wù)邏輯,其中比較典型的是消息中間件中的生產(chǎn)者,消費者負(fù)載均衡。

命名服務(wù)(Naming Service)

命名服務(wù)也是分布式系統(tǒng)中比較常見的一類場景。在分布式系統(tǒng)中,通過使用命名服務(wù),客戶端應(yīng)用能夠根據(jù)指定名字來獲取資源或服務(wù)的地址,提供者等信息。被命名的實體通??梢允羌褐械臋C器,提供的服務(wù)地址,遠程對象等等——這些我們都可以統(tǒng)稱它們?yōu)槊郑∟ame)。其中較為常見的就是一些分布式服務(wù)框架中的服務(wù)地址列表。通過調(diào)用 ZooKeeper 提供的創(chuàng)建節(jié)點的 API,能夠很容易創(chuàng)建一個全局唯一的path,這個 path 就可以作為一個名字。

阿里巴巴集團開源的分布式服務(wù)框架 Dubbo 中使用 ZooKeeper 來作為其命名服務(wù),維護全局的服務(wù)地址列表。在 Dubbo 的實現(xiàn)中:

  •     服務(wù)提供者在啟動的時候,向 ZooKeeper 上的指定節(jié)點 /dubbo/${serviceName}/providers 目錄下寫入自己的 URL 地址,這個操作就完成了服務(wù)的發(fā)布。
  •     服務(wù)消費者啟動的時候,訂閱/dubbo/serviceName/providers目錄下的提供者URL地址,并向/dubbo/{serviceName} /consumers 目錄下寫入自己的 URL 地址。

注意:所有向 ZooKeeper 上注冊的地址都是臨時節(jié)點,這樣就能夠保證服務(wù)提供者和消費者能夠自動感應(yīng)資源的變化。

另外,Dubbo 還有針對服務(wù)粒度的監(jiān)控。方法是訂閱 /dubbo/${serviceName} 目錄下所有提供者和消費者的信息。

分布式通知/協(xié)調(diào)

ZooKeeper 中特有 Watcher 注冊與異步通知機制,能夠很好的實現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào),實現(xiàn)對數(shù)據(jù)變更的實時處理。使用方法通常是不同系統(tǒng)都對 ZooKeeper 上同一個 Znode 進行注冊,監(jiān)聽 Znode 的變化(包括 Znode 本身內(nèi)容及子節(jié)點的),其中一個系統(tǒng) Update 了 Znode,那么另一個系統(tǒng)能夠收到通知,并作出相應(yīng)處理。

另一種心跳檢測機制:檢測系統(tǒng)和被檢測系統(tǒng)之間并不直接關(guān)聯(lián)起來,而是通過 ZooKeeper 上某個節(jié)點關(guān)聯(lián),大大減少系統(tǒng)耦合。

另一種系統(tǒng)調(diào)度模式:某系統(tǒng)有控制臺和推送系統(tǒng)兩部分組成,控制臺的職責(zé)是控制推送系統(tǒng)進行相應(yīng)的推送工作。管理人員在控制臺作的一些操作,實際上是修改了 ZooKeeper 上某些節(jié)點的狀態(tài),而 ZooKeeper 就把這些變化通知給它們注冊 Watcher 的客戶端,即推送系統(tǒng)。于是,作出相應(yīng)的推送任務(wù)。

另一種工作匯報模式:一些類似于任務(wù)分發(fā)系統(tǒng)。子任務(wù)啟動后,到 ZooKeeper 來注冊一個臨時節(jié)點,并且定時將自己的進度進行匯報(將進度寫回這個臨時節(jié)點)。這樣任務(wù)管理者就能夠?qū)崟r知道任務(wù)進度。

分布式鎖

分布式鎖主要得益于 ZooKeeper 為我們保證了數(shù)據(jù)的強一致性。鎖服務(wù)可以分為兩類:一類是保持獨占,另一類是控制時序。

所謂保持獨占,就是所有試圖來獲取這個鎖的客戶端,最終只有一個可以成功獲得這把鎖。通常的做法是把 ZooKeeper 上的一個 Znode 看作是一把鎖,通過 create znode的方式來實現(xiàn)。所有客戶端都去創(chuàng)建 /distribute_lock 節(jié)點,最終成功創(chuàng)建的那個客戶端也即擁有了這把鎖。

控制時序,就是所有視圖來獲取這個鎖的客戶端,最終都是會被安排執(zhí)行,只是有個全局時序了。做法和上面基本類似,只是這里 /distribute_lock 已經(jīng)預(yù)先存在,客戶端在它下面創(chuàng)建臨時有序節(jié)點(這個可以通過節(jié)點的屬性控制:CreateMode.EPHEMERAL_SEQUENTIAL 來指定)。ZooKeeper的父節(jié)點(/distribute_lock)維持一份 sequence,保證子節(jié)點創(chuàng)建的時序性,從而也形成了每個客戶端的全局時序。

由于同一節(jié)點下子節(jié)點名稱不能相同,所以只要在某個節(jié)點下創(chuàng)建 Znode,創(chuàng)建成功即表明加鎖成功。注冊監(jiān)聽器監(jiān)聽此 Znode,只要刪除此 Znode 就通知其他客戶端來加鎖。

創(chuàng)建臨時順序節(jié)點:在某個節(jié)點下創(chuàng)建節(jié)點,來一個請求則創(chuàng)建一個節(jié)點,由于是順序的,所以序號最小的獲得鎖,當(dāng)釋放鎖時,通知下一序號獲得鎖。

分布式隊列

隊列方面,簡單來說有兩種:一種是常規(guī)的先進先出隊列,另一種是等隊列的隊員聚齊以后才按照順序執(zhí)行。對于第一種的隊列和上面講的分布式鎖服務(wù)中控制時序的場景基本原理一致,這里就不贅述了。

第二種隊列其實是在 FIFO 隊列的基礎(chǔ)上作了一個增強。通??梢栽?/queue 這個 Znode 下預(yù)先建立一個 /queue/num 節(jié)點,并且賦值為 n(或者直接給 /queue 賦值 n)表示隊列大小。之后每次有隊列成員加入后,就判斷下是否已經(jīng)到達隊列大小,決定是否可以開始執(zhí)行了。

這種用法的典型場景是:分布式環(huán)境中,一個大任務(wù) Task A,需要在很多子任務(wù)完成(或條件就緒)情況下才能進行。這個時候,凡是其中一個子任務(wù)完成(就緒),那么就去 /taskList 下建立自己的臨時時序節(jié)點(CreateMode.EPHEMERAL_SEQUENTIAL)。當(dāng) /taskList 發(fā)現(xiàn)自己下面的子節(jié)點滿足指定個數(shù),就可以進行下一步按序進行處理了。

使用 dokcer-compose 搭建集群

上面我們介紹了關(guān)于 ZooKeeper 有這么多的應(yīng)用場景,那么接下來就先學(xué)習(xí)如何搭建 ZooKeeper 集群然后再進行實戰(zhàn)上面的應(yīng)用場景。

文件的目錄結(jié)構(gòu)如下: 

  1. ├── docker-compose.yml 

編寫 docker-compose.yml 文件

docker-compose.yml 文件內(nèi)容如下:

  1. version: '3.4'  
  2. services:  
  3.   zoo1:  
  4.     image: zookeeper  
  5.     restart: always  
  6.     hostname: zoo1  
  7.     ports:  
  8.       - 2181:2181  
  9.     environment:  
  10.       ZOO_MY_ID: 1  
  11.       ZOO_SERVERS: server.1=0.0.0.0:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=zoo3:2888:3888;2181  
  12.   zoo2:  
  13.     image: zookeeper  
  14.     restart: always  
  15.     hostname: zoo2  
  16.     ports:  
  17.       - 2182:2181  
  18.     environment:  
  19.       ZOO_MY_ID: 2  
  20.       ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=0.0.0.0:2888:3888;2181 server.3=zoo3:2888:3888;2181  
  21.   zoo3:  
  22.     image: zookeeper  
  23.     restart: always  
  24.     hostname: zoo3  
  25.     ports:  
  26.       - 2183:2181  
  27.     environment:  
  28.       ZOO_MY_ID: 3  
  29.       ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=0.0.0.0:2888:3888;2181 

在這個配置文件中,Docker 運行了 3 個 Zookeeper 鏡像,通過 ports 字段分別將本地的 2181, 2182, 2183 端口綁定到對應(yīng)容器的 2181 端口上。

ZOO_MY_ID 和 ZOO_SERVERS 是搭建 Zookeeper 集群需要的兩個環(huán)境變量。ZOO_MY_ID 標(biāo)識服務(wù)的 id,為 1-255 之間的整數(shù),必須在集群中唯一。ZOO_SERVERS 是集群中的主機列表。

在 docker-compose.yml 所在目錄下執(zhí)行 docker-compose up,可以看到啟動的日志。

連接 ZooKeeper

將集群啟動起來以后我們可以連接 ZooKeeper 對其進行節(jié)點的相關(guān)操作。

  •  首先需要下載 ZooKeeper。
  •  將其解壓。
  •  進入其 conf/ 目錄,將 zoo_sample .cfg 改成 zoo.cfg。

配置文件說明 

  1. # The number of milliseconds of each tick  
  2. # tickTime:CS通信心跳數(shù)  
  3. # Zookeeper 服務(wù)器之間或客戶端與服務(wù)器之間維持心跳的時間間隔,也就是每個 tickTime 時間就會發(fā)送一個心跳。tickTime以毫秒為單位。  
  4. tickTime=2000  
  5. # The number of ticks that the initial  
  6. # synchronization phase can take  
  7. # initLimit:LF初始通信時限  
  8. # 集群中的follower服務(wù)器(F)與leader服務(wù)器(L)之間初始連接時能容忍的最多心跳數(shù)(tickTime的數(shù)量)。  
  9. initLimit=5  
  10. # The number of ticks that can pass between  
  11. # sending a request and getting an acknowledgement  
  12. # syncLimit:LF同步通信時限  
  13. # 集群中的follower服務(wù)器與leader服務(wù)器之間請求和應(yīng)答之間能容忍的最多心跳數(shù)(tickTime的數(shù)量)。  
  14. syncLimit=2  
  15. # the directory where the snapshot is stored.  
  16. # do not use /tmp for storage, /tmp here is just  
  17. # example sakes.  
  18. # dataDir:數(shù)據(jù)文件目錄  
  19. # Zookeeper保存數(shù)據(jù)的目錄,默認(rèn)情況下,Zookeeper將寫數(shù)據(jù)的日志文件也保存在這個目錄里。  
  20. dataDir=/data/soft/zookeeper-3.4.12/data  
  21. # dataLogDir:日志文件目錄  
  22. # Zookeeper保存日志文件的目錄。  
  23. dataLogDir=/data/soft/zookeeper-3.4.12/logs  
  24. # the port at which the clients will connect  
  25. # clientPort:客戶端連接端口 
  26. # 客戶端連接 Zookeeper 服務(wù)器的端口,Zookeeper 會監(jiān)聽這個端口,接受客戶端的訪問請求。  
  27. clientPort=2181  
  28. # the maximum number of client connections.  
  29. # increase this if you need to handle more clients  
  30. #maxClientCnxns=60 
  31.  
  32. # Be sure to read the maintenance section of the  
  33. # administrator guide before turning on autopurge.  
  34.  
  35. # http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance  
  36.  
  37. # The number of snapshots to retain in dataDir  
  38. #autopurge.snapRetainCount=3  
  39. # Purge task interval in hours  
  40. # Set to "0" to disable auto purge feature  
  41. #autopurge.purgeInterval=1  
  42. # 服務(wù)器名稱與地址:集群信息(服務(wù)器編號,服務(wù)器地址,LF通信端口,選舉端口)  
  43. # 這個配置項的書寫格式比較特殊,規(guī)則如下:  
  44. server.N=YYY:A:B  
  45. # 其中N表示服務(wù)器編號,YYY表示服務(wù)器的IP地址,A為LF通信端口,表示該服務(wù)器與集群中的leader交換的信息的端口。B為選舉端口,表示選舉新leader時服務(wù)器間相互通信的端口(當(dāng)leader掛掉時,其余服務(wù)器會相互通信,選擇出新的leader)。一般來說,集群中每個服務(wù)器的A端口都是一樣,每個服務(wù)器的B端口也是一樣。但是當(dāng)所采用的為偽集群時,IP地址都一樣,只能時A端口和B端口不一樣。 

可以不修改 zoo.cfg,使用默認(rèn)配置。接下來在解壓后的 bin/ 目錄中執(zhí)行命令 ./zkCli.sh -server 127.0.0.1:2181 就能進行連接了。 

  1. Welcome to ZooKeeper!  
  2. 2020-06-01 15:03:52,512 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@1025] - Opening socket connection to server localhost/127.0.0.1:2181. Will not attempt to authenticate using SASL (unknown error) 
  3. JLine support is enabled  
  4. 2020-06-01 15:03:52,576 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@879] - Socket connection established to localhost/127.0.0.1:2181, initiating session 
  5. 2020-06-01 15:03:52,599 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@1299] - Session establishment complete on server localhost/127.0.0.1:2181, sessionid = 0x100001140080000, negotiated timeout = 30000 
  6. WATCHER::  
  7. WatchedEvent state:SyncConnected type:None path:null  
  8. [zk: 127.0.0.1:2181(CONNECTED) 0] 

接下來可以使用命令查看節(jié)點:

使用 ls 命令查看當(dāng)前 ZooKeeper 中所包含的內(nèi)容。命令:ls / 

  1. [zk: 127.0.0.1:2181(CONNECTED) 10] ls /  
  2. [zookeeper] 

創(chuàng)建了一個新的 znode 節(jié)點 zk 以及與它關(guān)聯(lián)的字符串。命令:create /zk myData 

  1. [zk: 127.0.0.1:2181(CONNECTED) 11] create /zk myData  
  2. Created /zk  
  3. [zk: 127.0.0.1:2181(CONNECTED) 12] ls /  
  4. [zk, zookeeper]  
  5. [zk: 127.0.0.1:2181(CONNECTED) 13] 

獲取 znode 節(jié)點 zk。命令:get /zk 

  1. [zk: 127.0.0.1:2181(CONNECTED) 13] get /zk  
  2. myData  
  3. cZxid = 0x400000008  
  4. ctime = Mon Jun 01 15:07:50 CST 2020  
  5. mZxid = 0x400000008  
  6. mtime = Mon Jun 01 15:07:50 CST 2020  
  7. pZxid = 0x400000008  
  8. cversion = 0  
  9. dataVersion = 0  
  10. aclVersion = 0  
  11. ephemeralOwner = 0x0  
  12. dataLength = 6  
  13. numChildren = 0 

刪除 znode 節(jié)點 zk。命令:delete /zk 

  1. [zk: 127.0.0.1:2181(CONNECTED) 14] delete /zk  
  2. [zk: 127.0.0.1:2181(CONNECTED) 15] ls /  
  3. [zookeeper]  

 

責(zé)任編輯:龐桂玉 來源: 民工哥技術(shù)之路
相關(guān)推薦

2013-07-16 14:44:43

Ubuntutftp服務(wù)器

2015-02-12 16:39:56

服務(wù)器宕機

2010-01-19 10:07:51

2010-07-15 13:54:25

最“搞”服務(wù)器

2009-11-30 11:33:50

sendmail服務(wù)器

2023-12-11 22:14:39

Docker鏡像容器

2017-01-15 17:44:27

Java EE服務(wù)器

2014-08-06 11:25:00

LinuxSVN服務(wù)器

2019-07-26 14:31:43

服務(wù)器集群部署

2017-08-07 10:02:03

DNS服務(wù)基礎(chǔ)

2021-09-10 10:07:17

Nginx虛擬主機服務(wù)器

2010-05-28 10:35:46

SVN搭建測試服務(wù)器

2013-05-14 11:22:48

路由器DNSDHCP

2009-07-22 19:06:37

2010-08-05 13:56:06

路由器配置

2015-06-12 10:48:18

2010-10-18 14:01:49

2015-08-25 15:34:51

2010-05-25 09:32:04

搭建SVN服務(wù)器

2016-08-10 16:28:00

WebURLHTTP
點贊
收藏

51CTO技術(shù)棧公眾號