[dubbo實戰] dubbo+zookeeper偽集群搭建
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文件
[html] view plain copy print?
- # The number of milliseconds of each tick
- tickTime=2000
- # The number of ticks that the initial
- # synchronization phase can take
- initLimit=10
- # The number of ticks that can pass between
- # sending a request and getting an acknowledgement
- syncLimit=5
- # the directory where the snapshot is stored.
- dataDir=E:/zookeeper/zookeeper-1/data
- # the directory where the log
- dataLogDir=E:/zookeeper/zookeeper-1/log
- # the port at which the clients will connect
- clientPort=2181
- #Clusters
- server.1=192.168.24.140(127.0.0.1):2888:3888
- server.2=192.168.24.140:2889:3889
- 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的地址,如下:
[html] view plain copy print?
- <!-- 本機 偽集群 測試 -->
- <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文件
[html] view plain copy print?
- # The number of milliseconds of each tick
- tickTime=2000
- # The number of ticks that the initial
- # synchronization phase can take
- initLimit=10
- # The number of ticks that can pass between
- # sending a request and getting an acknowledgement
- syncLimit=5
- # the directory where the snapshot is stored.
- dataDir=E:/zookeeper/zookeeper-1/data
- # the directory where the log
- dataLogDir=E:/zookeeper/zookeeper-1/log
- # the port at which the clients will connect
- clientPort=2181
- #Clusters
- server.1=192.168.24.140:2888:3888
- server.2=192.168.24.140:2889:3889
- server.3=192.168.24.140:2890:3890
每個zookeeper的端口配置都應該不同,分別是2181,2182,2183
4.在data文件添加myid文件,並且裏面的內容分別為:1,2,3
5.在dubbo項目中,provider和consumer的xml文件中修改zookeeper的地址,如下:
[html] view plain copy print?
- <!-- 本機 偽集群 測試 -->
- <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偽集群搭建