Zookeeper原始碼分析筆記[1]-客戶端原始碼分析
??ZooKeeper是一個分布式應用程式協調服務，提供的功能包括：配置維護、域名服務、分布式同步、組服務等，舉個例子，在分布式應用中，為了高可用，經常會使用主備架構，當主機掛了之后，自動切換到備機，這就需要有一個服務能感知主機下線【Zookeeper中的臨時節點】，并通知備機將自己升級為主機【Zookeeper的通知機制】，在主機和備機之間進行協調
??Zk自身也是一個分布式服務，其也有高可用問題，不同與Hdfs、Yarn等分布式框架，Zk的主節點是自己選出來的，也就是對應其快速選舉演算法，快速選舉能保證集群內當主節點宕機后，能從剩余Follower節點【Observer節點沒有投票和參與選主的權利】選出一個新主接管集群，為了用好這個技術，閑暇時間專門閱讀了Zk的源Zookeeper原始碼分析筆記系列文章主要對Zk運行中的重要流程進行介紹，本文使用的Zk版本是3.4.5，部分圖有點大，如果看不清可以，可到gitee下載一下，地址在文章末尾😂
1、初始化流程
??客戶端初始化一般都是用如下的語法：
new ZooKeeper(zkAddr,100000,watch)
以上代碼中
- zkAddr是zk的服務器地址和默認目錄節點【如有】，例如A:2181,B:2181/lock
- 100000是連接的超時時間
- watch是通知類，此時是默認的通知類，在連接成功后會觸發內部方法
初始化流程圖
為了保證下面文章的順滑，需要先說一下連接管理器類內部的兩個訊息佇列：outgoingQueue和pendingQueue，雖然叫佇列，其實就是個鏈表實作，客戶端所有的請求【事務請求和非事務請求，事務請求包括增刪改，非事務請求主要就是查】封裝之后都會先進入outgoingQueue，每個請求都有自己的唯一自增序號，請求發送出去后，該請求會被存盤到連接管理器的pendingQueue，服務端在接收到客戶端的請求后，會將該序號添加到回應體回傳給客戶端，客戶端接收到服務端的回應后，會依次從pendingQueue取出資料比對，如果出現亂序直接拋出例外，例如發送的順序是1,2,3，則接收的順序也必須是1,2,3
2、請求發送流程
??在發送請求時可以選擇同步和異步兩種方式，同步的方式必須等到服務端回傳回應后函式才會回傳，異步的方式是呼叫創建方法時需要注冊一個回呼函式，程式不會阻塞等待而是立即回傳，待收到服務端節點創建成功的回應后會回呼之前注冊的回呼函式，無論是哪種方式，呼叫方法后都是將請求寫到OutgoingQueue，佇列中的資料會在合適的時機由SendThread執行緒發送到服務端
2-1 同步方式請求發送流程圖
2-2 異步方式請求發送流程圖
3、資料發送執行緒SendThread流程決議
??SendThread的主要作用就是和服務端建立連接，并負責將客戶端的請求發送到服務端，網路主要使用的是Java的NIO，無NIO基礎的童鞋自己網上找點帖子補一補吧，核心組件就是多路復用器Selector，Linux上主要呼叫的底層函式就是epoll，相比于C和C++，Java已經封裝的有點好了
3-1 執行緒run方法整體流程
??只要是個執行緒，其啟動之后最終呼叫的就輸run方法，SendThread的run方法的整體流程如下，圖中紅色部分是重要的主流程，會在后續內容詳細分析，這個圖稍微有那么一點點大【圖片編號：image-20211224105628279.png】
3-2 連接服務器
??客戶端啟動之后肯定沒和服務端建立聯系，所以要想向服務端發送請求，第一步就是建立網路連接，建立網路連接的流程如下：
3-3 網路IO處理的主函式doTransport主流程
??客戶端連接建立好之后的下一步就是將請求發送給服務端，無論是發送請求還是接收回應，最終都是由SendThread的doTransport負責，其主要流程如下【圖片編號：image-20211224110657675.png】：
??對Java NIO熟悉的童鞋應該對這個代碼很熟的吧，主要就是通過Selector的select方法回傳有IO事件的SelectionKey，然后遍歷處理，我們這主要關系讀操作和寫操作
3-4 網路寫操作
??又是一張大圖【圖片編號：image-20211224111443970.png】
具體內容都在圖里了😂
3-5 網路讀操作
??Tcp網路通信中都會存在粘包和拆包的問題，只要使用TCP傳輸，都需要解決這個問題，Zk解決粘包拆包的問題使用的方案和很多主流框架大致一樣，使用兩個buffer，代碼中稱為incomingBuffer和lenbuffer，這兩個buffer都是用來接收資料，但是作用有所不同，lenbuffer的長度固定為4個位元組【Int型別】，結合上面的資料格式可以看出，這4位元組就是資料包的長度，接收到長度后會開辟對應長度的空間，并將其賦值給incomingBuffer用于存盤實際從服務端接收的資料包，只有incomingBuffer存滿了，才說明一個完整的資料包接收完成，初始情況下incomingBuffer和lenbuffer指向同一記憶體區域，后續會根據其是否指向同一記憶體區域來區分是讀取資料包長度還是可以開始讀取資料，讀操作的整體流程圖：
客戶端需要從網路讀取的資料主要有兩大類
- 客戶端連接的回應資料，里面存盤了客戶端的唯一ID
- 正常的回應資料
3-5-1 客戶端連接回應資料
??客戶端和服務端創建連接后會馬上發送連接請求給服務端，主要目的是為了獲取客戶端唯一標識，也就是一直說的會話ID，有這個會話ID，Zk服務端就能動態感知客戶端的上下線
那么是不是有個問題，客戶端要這個東西干啥？
想象一下這個情況，如果客戶端連接到Zk的某臺服務器后，這臺服務器掛了！！！網路就得重連，但是客戶端還是那個客戶端，總不能因為服務端自己掛了，就不認識這些已連接的會話了吧，所以客戶端需要自己存盤一下這個會話ID，在重連時封裝到請求發送到服務端，服務端看到這個ID后，才知道這個客戶端不是新的，也就不會洗掉其創建的一系列臨時節點
整體流程圖如下：
3-5-2 正常的回應資料
??正常回應資料的型別比較多，主要是通過回應的回應頭標識，我們在這主要分析通知訊息和請求回應，其中請求回應最侄訓呼叫FinishPacket函式處理，無論哪種想用最終都會將處理結果放到EventThread的WaitingEvents佇列中，回應的整體處理流程圖如下：
上圖的通知訊息處理流程中解釋了為啥Zk的通知只有一次有效
FinishPacket函式的處理流程如下：
概括一下主要功能就是：
- 如果發送請求時需要接收后續服務端的通知訊息，則將訊息處理物件注冊到內部的通知管理器
- 呼叫回呼方法【異步】或者喚醒資料發送執行緒【同步】
4、事件處理執行緒EventThread流程決議
??上面說到服務端發送的回應或者通知訊息最終都會放到EventThread的WaitingEvents佇列中，執行緒的run方法會持續從佇列中取出事件進行處理，整體的處理流程如下：
5、圖片地址
圖片的gitee地址：https://gitee.com/source-code-note/graph/tree/master/zookeeper
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/423272.html
標籤：其他