zookeeper作為註冊中心，服務器和客戶端都要訪問，如果有大量的並發，肯定會有等待。所以可以通過zookeeper集群解決。

一、為什麽需要zookeeper呢？

大部分分布式應用需要一個主控、協調器或者控制器來管理物理分布的子進程。目前，大多數都要開發私有的協調程序，缺乏一個通用機制，協調程序的反復編寫浪費，且難以形成通用、伸縮性好的協調器，zookeeper提供通用的分布式鎖服務，用以協調分布式應用。所以說zookeeper是分布式應用的協作服務。

二、zookeeper的工作原理

核心原理是原子廣播，這個機制保證了各個server之間的同步，實現這個機制的協議叫做Zab協議，它有兩種模式：恢復和廣播模式。

當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，恢復模式就結束了。

一旦zookeeper內部同步好了後，就可以開始廣播信息了，這時候當一個server加入zookeeper服務中，它會在恢復模式下啟動，並且同步狀態，同步結束後它也參與廣播消息。

三、集群搭建準備

1.我用了三個zookeeper服務，分別是zookeeper-1，zookeeper-2，zookeeper-3

2.在每個zookeeper下添加data和log文件

3.配置zoo.cfg文件

1. # The number of milliseconds of each tick
2. tickTime=2000
3. # The number of ticks that the initial
4. # synchronization phase can take
5. initLimit=10
6. # The number of ticks that can pass between
7. # sending a request and getting an acknowledgement
8. syncLimit=5
9. # the directory where the snapshot is stored.
10. dataDir=E:/zookeeper/zookeeper-1/data
11. # the directory where the log
12. dataLogDir=E:/zookeeper/zookeeper-1/log
13. # the port at which the clients will connect
14. clientPort=2181
15. #Clusters
16. server.1=192.168.24.140（127.0.0.1）:2888:3888
17. server.2=192.168.24.140:2889:3889
18. server.3=192.168.24.140:2890:3890

每個zookeeper的端口配置都應該不同，分別是2181，2182，2183

4.在data文件添加myid文件（touch myid），並且裏面的內容分別為：1，2，3

5.在dubbo項目中，provider和consumer的xml文件中修改zookeeper的地址，如下：

1. <!-- 本機 偽集群 測試 -->
2. <dubbo:registry protocol="zookeeper" address="192.168.24.140:2181,192.168.24.140:2182,192.168.24.140:2183" />

四、測試

先分別啟動zookeeper，然後依次啟動服務和客戶端。啟動服務的時候會看到連接到哪個zookeeper上了。為了測試集群的特性，比如客戶端啟動後zookeeper-1提供服務，我關掉它，那麽程序就繼續發起連接，接著可能zookeeper-2提供服務。

因為現在有三臺服務器，所以要求至少有2臺正常啟動才能運行正常。那麽zookeeper-2也關閉，那程序不會連接zookeeper-3，一直報錯，提示no further connection。

上面說了停掉某個服務，zookeeper內部會選舉出下一個leader來，它內部存在投票選舉機制。這裏不多說了。就像MongoDB集群，會根據心跳機制選出主服務器。

接下來的測試，我繼續打開zookeeper-1或zookeeper-2，能正常提供服務。把zookeeper-3關閉，如果zookeeper-1和zookeeper-2重新啟動成功後，也是能提供服務的。內部在恢復模式下同步狀態。

zookeeper作為註冊中心，服務器和客戶端都要訪問，如果有大量的並發，肯定會有等待。所以可以通過zookeeper集群解決。

一、為什麽需要zookeeper呢？

大部分分布式應用需要一個主控、協調器或者控制器來管理物理分布的子進程。目前，大多數都要開發私有的協調程序，缺乏一個通用機制，協調程序的反復編寫浪費，且難以形成通用、伸縮性好的協調器，zookeeper提供通用的分布式鎖服務，用以協調分布式應用。所以說zookeeper是分布式應用的協作服務。

二、zookeeper的工作原理

核心原理是原子廣播，這個機制保證了各個server之間的同步，實現這個機制的協議叫做Zab協議，它有兩種模式：恢復和廣播模式。

當服務啟動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，恢復模式就結束了。

一旦zookeeper內部同步好了後，就可以開始廣播信息了，這時候當一個server加入zookeeper服務中，它會在恢復模式下啟動，並且同步狀態，同步結束後它也參與廣播消息。

三、集群搭建準備

1.我用了三個zookeeper服務，分別是zookeeper-1，zookeeper-2，zookeeper-3

2.在每個zookeeper下添加data和log文件

3.配置zoo.cfg文件

1. # The number of milliseconds of each tick
2. tickTime=2000
3. # The number of ticks that the initial
4. # synchronization phase can take
5. initLimit=10
6. # The number of ticks that can pass between
7. # sending a request and getting an acknowledgement
8. syncLimit=5
9. # the directory where the snapshot is stored.
10. dataDir=E:/zookeeper/zookeeper-1/data
11. # the directory where the log
12. dataLogDir=E:/zookeeper/zookeeper-1/log
13. # the port at which the clients will connect
14. clientPort=2181
15. #Clusters
16. server.1=192.168.24.140:2888:3888
17. server.2=192.168.24.140:2889:3889
18. server.3=192.168.24.140:2890:3890

每個zookeeper的端口配置都應該不同，分別是2181，2182，2183

4.在data文件添加myid文件，並且裏面的內容分別為：1，2，3

5.在dubbo項目中，provider和consumer的xml文件中修改zookeeper的地址，如下：

1. <!-- 本機 偽集群 測試 -->
2. <dubbo:registry protocol="zookeeper" address="192.168.24.140:2181,192.168.24.140:2182,192.168.24.140:2183" />

四、測試

先分別啟動zookeeper，然後依次啟動服務和客戶端。啟動服務的時候會看到連接到哪個zookeeper上了。為了測試集群的特性，比如客戶端啟動後zookeeper-1提供服務，我關掉它，那麽程序就繼續發起連接，接著可能zookeeper-2提供服務。

因為現在有三臺服務器，所以要求至少有2臺正常啟動才能運行正常。那麽zookeeper-2也關閉，那程序不會連接zookeeper-3，一直報錯，提示no further connection。

上面說了停掉某個服務，zookeeper內部會選舉出下一個leader來，它內部存在投票選舉機制。這裏不多說了。就像MongoDB集群，會根據心跳機制選出主服務器。

接下來的測試，我繼續打開zookeeper-1或zookeeper-2，能正常提供服務。把zookeeper-3關閉，如果zookeeper-1和zookeeper-2重新啟動成功後，也是能提供服務的。內部在恢復模式下同步狀態。

[dubbo實戰] dubbo+zookeeper偽集群搭建