zookeeper集群

環境：

• 擁有三台服務器，假設三台服務器的Ip地址為 172.18.19.143，172.18.19.15，172.18.19.129
• 開放三台服務器的2287，3387端口

集群搭建步驟：

1. 修改zookeeper服務器對應的配置文件：添加

server.1=172.18.19.143:2287:3387
server.2=172.18.19.15:2287:3387
server.3=172.18.19.129:2287:3387

說明：

#集群配置信息
#server.A=B:C:D
# A:是一個數字,表示這個是服務器編號
# B:是這個服務器的ip地址
# C:zk服務器之間的通信端口
# D:Leader選舉的端口

2. 在zk的新建的data目錄下新建文件myid,將步驟1中的數字A添加到文件中

3. 使用./zkCli.sh -server 172.18.19.143:2181 登錄指定的服務器

至此，集群已搭建完成。

zookeeper一致性協議：

zab協議全稱為Zookeeper Atomic Broadcat(zk原子廣播)。zk是通過zab協議來保證分布式事務的最終一致性。

基於zab協議,zk集群中的角色主要有以下三類：

• Leader: 領導者負責進行投票的發起和決議,更新系統狀態。
• Learner:
  • Follower: Follower用於接收客戶請求並向客戶端返回結果,在選舉過程中參與投票
  • Observer: Observer可以接收客戶端連接,將寫請求轉發給leader節點。但Observer不參與投票過程,只同步leader的狀態。Observer的目的是為了擴展系統,以提高讀取速度。
• Client:請求發起方

寫請求保持一致性過程：

1. leader從客戶端收到一個寫請求
2. leader生成一個新的事務並為這個事務生成一個唯一的ZXID
3. leader將這個事務提議(propose)發送給所有的follows節點
4. follower節點將收到的事務請求加入到歷史隊列(history queue)中,並發送ack給leader
5. 當leader收到大多數follower(半數以上節點)的ack消息,leader會發送commit請求
6. 當follower收到commit請求時,從歷史隊列中將事務請求commit

zookeeper的leader選舉：

服務器狀態：

• looking:尋找leader狀態。當服務器處於該狀態時,它會認為當前集群沒有leader,因此需要進入leader選舉狀態。
• leading:領導者狀態。表明當前服務器角色是leader.
• following: 跟隨者狀態。表明當前服務器角色是follower。
• observing: 觀察者狀態。表明當前服務器角色是Observer。

服務器啟動時期的leader選舉：

在集群初始化階段,當有一台服務器server1啟動時,其單獨無法進行和完成leader選舉,當第二台服務器server2啟動時,此時兩台機器可以相互通信,每台機器都試圖找到leader,於是進入leader選舉過程。選舉過程如下：

1. 每個server發出一個投票。由於是初始情況,server1和server2都會將自己作為leader服務器來進行投票,每次投票會包含所推舉的服務器的myid和zxid,使用(myid,zxid)來表示,此時server1的投票為(1,0),server2的投票為(2,0),然后各自將這個投票發給集群中的其它機器。
2. 集群中的每台服務器接收來自集群中各個服務器的投票。
3. 處理投票。針對每一個投票,服務器都需要將別人的投票和自己的投票進行Pk,pk規則如下：　　
   • 優先檢查zxid。zxid比較大的服務器優先作為leader。
   • 如果zxid相同,那么就比較myid。myid較大的服務器作為leader服務器。
   • 對於server1而言,它的投票是(1,0),接收server2的投票為(2,0),首先會比較兩者的zxid,均為0,再比較myid,此時server2的myid最大,於是更新自己的投票為(2,0),然后重新投票;對於server2而言,其無需更新自己的投票,只是再次向集群中所有機器發出上一次投票信息即可
4. 統計投票。每次投票后,服務器都會統計投票信息,判斷是否已經有過半機器接收到相同的投票信息,對於server1、server2而言,都統計出集群中已經有兩台機器接收了(2,0)的投票信息,此時便認為已經選舉出了leader。
5. 改變服務器狀態。一旦確定了leader,每個服務器就會更新自己的狀態,如果是follower,那么就變更為following,如果是leader,就會變更為leading。

服務器運行時期的Leader選舉：

在zk運行期間,leader與非leader服務器各司其職,即便當有非leader服務器宕機或者新加入,此時也不會影響leader,但是一旦leader服務器宕機了,那么整個集群將會暫停對外服務,進入新一輪leader選舉,其過程和啟動時期的Leader選舉過程基本一致。

假設正在運行的有server1,server2,server3三台服務器,當前leader是server2,若某一時刻leader掛了,此時便開始leader選舉。選舉過程如下：

1. 變更狀態。leader掛后,余下的服務器會將自己的服務器狀態變更為looking,然后開始進入leader選舉過程。
2. 每個server會發出一個投票。在運行期間,每個服務器上的zxid可能不同,此時假定server1的zxid為122,server3的zxid為122,在第一輪投票中,server1和server3都會投自己,產生投票(1,122),(3,122),然后各自將自己的投票發送給集群中的所有機器。
3. 接收來自各個服務器的投票.與啟動過程相同。
4. 處理投票。與啟動過程相同。此時,server3將會成為leader.
5. 統計投票。與啟動時過程相同。
6. 改變服務器的狀態。與啟動時過程相同。

observer角色及其配置：

observer角色特點：

1. 不參與集群的leader選舉
2. 不參與集群中寫數據時的ack反饋

配置步驟：

1. 為了使用observer角色,在任何想編程observer角色的配置文件中加入如下配置：

   • peerType=observer

   • 在所有server的配置文件中,配置成observer模式的server的那行配置追加:observer,例如：

     server.3=192.168.60.130:2289:3389:observer