Unit4：大資料技術進階（Zookeeper）

本章節學習目標：

1. 了解zookeeper的概述和架構
2. 掌握集群中各個角色的作用
3. 熟悉zookeeper集群的搭建
4. 掌握內部原理
5. 企業面試真題

一、大資料概念

1 概論:

zookeeper是什么？

1， Zookeeper是一個分布式協調服務的開源概架，主要用來解決分布式集群中應用系統的一致性問題，

2 ，ZooKeeper本質上是一個分布式的小檔案存盤系統，提供基于類似于檔案系統的目錄樹方式的資料存盤，并且可以對樹中的節點進行有效管理，從而用來維護和監控你存盤的資料的狀態變化，通過監控這些資料狀態的變化，從而可以達到基于資料的集群管理，諸如：統一命名服務、分布式配置管理、負載均衡、分布式鎖、分布式協調等功能，

（詳見官網：https://zookeeper.apache.org/）

2 特點 :

zookeeper的幾大特性分別是什么？

Zookeeper：是由一個領導者（Leader），多個跟隨者（Follower）組成的集群，
集群中只要有半數以上的節點存活下來，Zookeeper集群就能正常服務，
全域資料一致：每個Server保存一份相同的資料副本，Client無論連接那個Server，資料都是一致的，
可靠性：如果訊息被其中的一臺服務器接收，那么就被所有的服務器接收，
順序性：更新請求順序進行，來自同一個Client的更新請求按照發送順序依次執行，
資料更新原子性：一次資料更新要么成功，要么失敗，不存在其他狀態，
實時性：Zookeeper保證客戶端在一定事件間隔范圍內獲取服務器的更新（或失效）的資訊，
集群中半數以上機器存活，集群可用，所以Zookeeper適合安裝奇數臺服務器，

3 集群中角色的作用

各個角色代表著什么？

1. Leader:

Zookeeper 集群作業的核心
事務請求 (寫操作) 的唯一調度和處理者，保證集群事務處理的順序性
集群內部各個服務器的調度者，
對于 create, setData, delete 等有寫操作的請求，則需要統一轉發給leader 處理.leader 需要決定編號、執行操作，這個程序稱為一個事務，

1. Follower:

處理客戶端非事務(讀操作)請求，轉發事務請求給 Leader
參與集群Leader 選舉投票，

3. Observer:（對于訪問量比較大的集群，可以新增觀察者角色）

觀察者角色，觀察Zookeeper集群的最新狀態變化并將這些狀態同步過來，對于非事務請求可以進行獨立處理，對于事務請求，則會轉發給 Leader服務器進行處理，
不會參與任何形式的投票只提供非事務服務，通常用于在不影響集群事務處理能力的前提下提升集群的非事務處理能力，

4 資料結構

Zookeeper資料模型的結構與Unix檔案系統相似，呈樹狀圖分布，每個節點稱為一個ZNode，每個與ZNode默認只能存盤1M的資料，每個ZNode都可以通過路徑使標識唯一，

每個ZNode有三部分組成：

stat：狀態資訊，顯示ZNode版本，權限等資訊，
data：與ZNode關聯的資料，
children：本ZNode下的子節點，

二、API應用

Eclipse

創建maven工程
添加pom檔案

<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>RELEASE</version>
		</dependency>
		<dependency>
			<groupId>org.apache.logging.log4j</groupId>
			<artifactId>log4j-core</artifactId>
			<version>2.8.2</version>
		</dependency>
		<!-- https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper -->
		<dependency>
			<groupId>org.apache.zookeeper</groupId>
			<artifactId>zookeeper</artifactId>
			<version>3.4.10</version>
		</dependency>
</dependencies>

創建log4j.properties檔案并添加如下內容

log4j.rootLogger=INFO, stdout  
log4j.appender.stdout=org.apache.log4j.ConsoleAppender  
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout  
log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n  
log4j.appender.logfile=org.apache.log4j.FileAppender  
log4j.appender.logfile.File=target/spring.log  
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout  
log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n

創建客戶端

private static String connectString =
 "hadoop102:2181,hadoop103:2181,hadoop104:2181";
	private static int sessionTimeout = 2000;
	private ZooKeeper zkClient = null;

	@Before
	public void init() throws Exception {

	zkClient = new ZooKeeper(connectString, sessionTimeout, new Watcher() {

			@Override
			public void process(WatchedEvent event) {

				// 收到事件通知后的回呼函式（用戶的業務邏輯）
				System.out.println(event.getType() + "--" + event.getPath());

				// 再次啟動監聽
				try {
					zkClient.getChildren("/", true);
				} catch (Exception e) {
					e.printStackTrace();
				}
			}
		});
	}

創建子節點

// 創建子節點
@Test
public void create() throws Exception {

		// 引數1：要創建的節點的路徑； 引數2：節點資料 ； 引數3：節點權限 ；引數4：節點的型別
		String nodeCreated = zkClient.create("/jinghang", "jinlian".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
}

獲取子節點并監聽節點變化

// 獲取子節點
@Test
public void getChildren() throws Exception {

		List<String> children = zkClient.getChildren("/", true);

		for (String child : children) {
			System.out.println(child);
		}

		// 延時阻塞
		Thread.sleep(Long.MAX_VALUE);

判斷ZNode是否存在

// 判斷znode是否存在
@Test
public void exist() throws Exception {

	Stat stat = zkClient.exists("/eclipse", false);

	System.out.println(stat == null ? "not exist" : "exist");
}

三、內部原理（重點）

1 節點型別

型別分為兩大類
持久節點：客戶端與服務器斷開連接之后，創建的節點始終存在，
臨時節點：客戶端與服務器斷開連接之后，節點自動洗掉，

持久化目錄節點：客戶端與Zookeeper斷連之后，創建的節點依舊存在，
持久化順序編號目錄節點：同持久化目錄節點，只是Zookeeper給該節點名稱進行順序編號，
臨時目錄節點：客戶端與Zookeeper斷連之后，創建的節點被洗掉，
臨時順序編號目錄節點：同臨時目錄節點，只是Zookeeper給該節點名稱進行順序編號，

3 stat結構體

Stat 結構體相關引數,須知：

czxid-創建節點的事務zxid
ctime - znode被創建的毫秒數(從1970年開始)
mzxid - znode最后更新的事務zxid
mtime - znode最后修改的毫秒數(從1970年開始)
pZxid-znode最后更新的子節點zxid
cversion - znode子節點變化號，znode子節點修改次數（須知）
dataversion - znode資料變化號（修改一次會加一）（須知）
ephemeralOwner- 如果是臨時節點，這個是znode擁有者的session id，如果不是臨時節點則是0x0，（須知）
dataLength- znode的資料長度（須知）
numChildren - 子節點數量（須知）

4 Leader選舉機制

1） 舊集群選舉：
資料ID、服務器ID和邏輯時鐘含義說明：
資料ID：資料新的version就大，資料每次更新都會更新version，
服務器ID：就是我們配置的myid中的值，每個機器一個，
邏輯時鐘：這個值從0開始遞增,每次選舉對應一個值，如果在同一次選舉中,這個值是一致的，
選舉的標準為：

邏輯時鐘小的選舉結果被忽略，重新投票；
統一邏輯時鐘后，資料id大的勝出，當選leader；
資料id相同的情況下，服務器id大的勝出，當選leader；

2） 全新集群選舉：

采用投票機制，每臺服務器自帶一票默認投給自己，一旦遇到服務器id比自己大的就會將自身寶貴的一票貢獻出來，直到有一臺服務器的票數大于所有服務器總數的一半時，Leader誕生，所有Follower改變狀態，不在參與選舉，

5 監聽器原理

首先要有一個main()執行緒
在main執行緒中創建Zookeeper客戶端，這時就會創建兩個執行緒，一個負責網路連接通信（connet），一個負責監聽（listener）
通過connect執行緒將注冊的監聽事件發送給Zookeeper
在Zookeeper的注冊監聽器串列中將注冊的監聽事件添加到串列中
Zookeeper監聽到有資料或路徑變化，就會將這個訊息發送給listener執行緒
listener執行緒內部呼叫process()方法

6 寫資料流程

Client向ZooKeeper的Server1 寫資料，發送一個寫請求
如果Server1不是Leader，那么Server1會把接受到的這個事務請求進一步轉發給Leader，
Leader會將寫請求廣播給各個Server，各個Server寫成功后，會向Leader發送成功資訊
當Leader收到半數以上（大多數） Server資料寫成功的資訊，說明該資料寫成功了，Leader會告訴server1資料寫成功了.
Server1會進一步通知 Client 資料寫成功了，就認為整個寫操作成功

7 監聽服務器節點動態上下線案例（擴展）

參考：https://blog.csdn.net/m0_51113511/article/details/112412308

四、面試官拷問：

請簡述ZooKeeper的選舉機制？
ZooKeeper的監聽原理是什么？
ZooKeeper的部署方式有哪幾種？集群中的角色有哪些？集群最少需要幾臺機器？
ZooKeeper的常用命令？
Zookeeper 下 Server作業狀態都有什么？
資料是怎樣進行同步的？

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/247174.html

標籤：其他

上一篇：ckeditor5富文本數學化學方程式

下一篇：Hive-JDBC流程