Zookeeper集群部署

zookeeper的選舉機制

假設有五颱伺服器組成的zookeeper集群,它們的id從1-5,同時它們都是最新啟動的,也就是沒有歷史資料,在存放資料量這一點上,都是一樣的.假設這些伺服器依序啟動。

伺服器1啟動，但沒過半數，

伺服器2啟動,它與最開始啟動的伺服器1進行通訊,互相交換自己的選舉結果,由於兩者都沒有歷史資料,所以id值較大的伺服器2勝出,但是由於沒有達到超過半數以上的伺服器都同意選舉它(這個例子中的半數以上是3),所以伺服器1,2還是繼續保持looking狀態；

伺服器3啟動,根據前面的理論分析,伺服器3成為伺服器1,2,3中的老大,而與上面不同的是,此時有三颱伺服器選舉了它,所以它成為了這次選舉的leader.

伺服器4啟動,根據前面的分析,理論上伺服器4應該是伺服器1,2,3,4中最大的,但是由於前面已經有半數以上的伺服器選舉了伺服器3,所以它只能接收當小弟的命了.

伺服器5啟動,同4一樣,當小弟

如果不是順序啟動，就看第三次啟動的時候誰最大了

真實的集群是需要部署在不同的伺服器上的，但是在我們測試時同時啟動十幾個虛擬機器記憶體會吃不消，所以我們通常會搭建偽集群，也就是把所有的服務都搭建在一台虛擬機器上，用埠進行區分。這裡，我直接在三颱真實伺服器上進行搭建。

三颱伺服器的ip分別是 10.xx.***.232(ubuntu02) 10.xx.***.233(ubuntu03) 10.xx.***.234(ubuntu04)

首先每台伺服器上要進行jdk的安裝，這裡不再贅述，網上有很多

然後通過 xftp 把 zookeeper 的壓縮包傳到伺服器上進行解壓

建立data資料夾用來存放資料

進入 conf 下修改 zoo_sample.cfg 檔名為 zoo.cfg

通過scp命令，將zookeeper資料夾遠端傳送到另外兩台機器上

修改conf下面的zoo.cfg檔案，將datadir修改為我們剛剛建立的data資料夾

另外兩台機子同樣如此

在每個zookeeper的 data 目錄下建立乙個 myid 檔案，內容分別是1、2、3 。這個檔案就是記錄每個伺服器的id

每個節點的配置檔案zoo.cfg中去配置

啟動第一台機器，發現沒有啟動，那是因為集群要超過半數才能正常啟動，少於半數無法執行

開啟第二台機器發現

啟動成功

模擬集群異常

如果停掉第三台機器，發現第一台和第二台狀態都沒有變化

如果此時再把第一台機器停掉，發現第二台伺服器已經停止執行

此時再把第一台機器執行起來，發現第二台伺服器又可以正常執行，而且依然是領導者

如果把第三台重啟啟動，掛掉第二台，發現第三台成為最新的領導者，也就是當集群中的主伺服器掛了，集群中的其他伺服器會自動進行選舉狀態，然後產生新的 leader

如果重新啟動第二台伺服器，發現第二台變為跟隨著，第三台依然是領導者，也就是說，當領導者產生後，再次有新伺服器加入集群，不會影響到現任的leader

dubbo 連線 zookeeper 集群

修改服務提供者和服務呼叫者的spring 配置檔案

dubbo:registry

protocol

="zookeeper"

address="

10.xx.***.232:2181,10.xx.***.233:2181,10.xx.***.234:

2181"

dubbo:registry