今天我們來說一說Zookeeper內部原理中的請求、事務和識別符號，
ZooKeeper服務器會在本地處理只讀請求（exists、getData和getChildren），如?個服務器接收到客戶端的getData請求，服務器讀取該狀態資訊，并將這些資訊回傳給客戶端，因為服務器會在本地處理請求，所以ZooKeeper在處理以只讀請求為主要負載時，性能會很?，我們還可以增加更多的服務器到ZooKeeper集群中，這樣就可以處理更多的讀請求，?幅提?整體處理能?，
那些會改變ZooKeeper狀態的客戶端請求（create、delete和setData）將會被轉發給群?，群?執?相應的請求，并形成狀態的更新，我們稱為事務（transaction），其中，請求表?源?于客戶端發起的操作，?事務則包含了對應請求處理?改變ZooKeeper狀態所需要執?的步驟，我們通過?個簡單點的例?，?不是ZooKeeper的操作，來說明這個問題，
假如，操作為inc（i），該?法對變數i的值進?增量操作，如果此時?個請求為inc（i），假如i的值為10，該操作執?后，其值為11，再回過頭看請求和事務的概念，其中inc（i）為請求，?事務則為變數i和11（變數i保存了11這個值），
現在我們再來看看ZooKeeper的例?，假如?個客戶端提交了?個對/z節點的setData請求，setData將會改變該znode節點資料資訊，并會增加該節點的版本號，因此，對于這個請求的事務包括了兩個重要欄位：節點中新的資料欄位值和該節點新的版本號，當處理該事務時，服務端將會?事務中的資料資訊來替換/z節點中原來的資料資訊，并會?事務中的版本號更新該節點，?不是增加版本號的值，
?個事務為?個單位，也就是說所有的變更處理需要以原??式執?，
以setData的操作為例，變更節點的資料資訊，但并不改變版本號將會導致錯誤的發?，因此，ZooKeeper集群以事務?式運?，并確保所有的變更操作以原??式被執?，同時不會被其他事務所?擾，在ZooKeeper中，并不存在傳統的關系資料庫中所涉及的回滾機制，?是確保事務的每?步操作都互不?擾，在很長的?段時間?，ZooKeeper所采?的設計?式為，在每個服務器中啟動?個單獨的執行緒來處理事務，通過單獨的執行緒來保障事務之間的順序執?互不?擾，最近，ZooKeeper增加了多執行緒的?持，以便提?事務處理的速度，
同時?個事務還具有冪等性，也就是說，我們可以對同?個事務執?兩次，我們得到的結果還是?樣的，我們甚?還可以對多個事務執?多次，同樣也會得到?樣的結果，前提是我們確保多個事務的執?順序每次都是?樣的，事務的冪等性可以讓我們在進?恢復處理時更加簡單，當群?產?了?個事務，就會為該事務分配?個識別符號，我們稱之為ZooKeeper會話ID（zxid），通過Zxid對事務進?標識，就可以按照群?所指定的順序在各個服務器中按序執?，服務器之間在進?新的群?選舉時也會交換zxid資訊，這樣就可以知道哪個?故障服務器接收了更多的事務，并可以同步他們之間的狀態資訊，
zxid為?個long型（64位）整數，分為兩部分：
- 時間戳（epoch）部分
- 計數器（counter）部分，
每個部分為32位，在我們討論zab協議時，我們就會發現時間戳（epoch）和計數器（counter）的具體作?，我們通過該協議來?播各個服務器的狀態變更資訊，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/233160.html
標籤：其他