摘要:要想保證負(fù)載均衡得再結(jié)合部署方案,配置網(wǎng)絡(luò)連接器。編碼時(shí),端消費(fèi)者通過協(xié)議來連接集群。一服務(wù)器配置集群集群保證本身的高可用性。只需使用進(jìn)行配置即可,默認(rèn)端口為。
前言
本案例使用的是真集群方式,準(zhǔn)備三臺(tái)主機(jī),IP分別為192.168.100.142、192.168.100.143、192.168.100.144
偽集群部署請看:ActiveMQ+ZooKeeper 偽集群整合
如果需要了解ActiveMQ集群部署的整體概念,可以參考我這篇文章:ActiveMQ集群整體認(rèn)識(shí)
原理簡介:
一般在部署ActiveMQ集群的時(shí)候,更傾向于使用基于ZooKeeper的Replicated LevelDB Store方式,該方式是Master Slave部署方案的其中一種策略,也是在多臺(tái)主機(jī)實(shí)現(xiàn)ActiveMQ集群的主流部署方式。 此教程只保證了高可用性。要想保證負(fù)載均衡得再結(jié)合Broker Clusters 部署方案,配置網(wǎng)絡(luò)連接器。
工作流程:
在ZooKeeper中管理多個(gè)Broker節(jié)點(diǎn),根據(jù) Master選舉策略讓其中一個(gè) Broker選舉為Master(只有Master才具備對(duì)外提供服務(wù)的能力),剩下Broker為slave。
編碼時(shí),client端(消費(fèi)者)通過failover協(xié)議來連接ActiveMQ集群。
ZooKeeper集群保證ZooKeeper本身的高可用性。
1.1 修改ZK配置文件conf/zoo.cfg主機(jī)IP | 服務(wù)端口(默認(rèn)) | 集群通信端口 | 節(jié)點(diǎn)目錄/opt/下 | |
---|---|---|---|---|
192.168.100.142 | 2181 | 2888:3888 | zookeeper | |
192.168.100.143 | 2181 | 2888:3888 | zookeeper | |
192.168.100.144 | 2181 | 2888:3888 | zookeeper |
集群通信端口:第一個(gè)端口是master和slave之間的通信端口,默認(rèn)是2888;第二個(gè)端口是leader選舉的端口,集群剛啟動(dòng)的時(shí)候選舉或者leader掛掉之后進(jìn)行新的選舉的端口默認(rèn)是3888。
在3臺(tái)主機(jī)上都安裝zookeeper服務(wù),/opt/zookeeper,并分別配置它們的文件conf/zoo.cfg:
主機(jī)1(192.168.100.142):
/opt/zookeeper/conf/zoo.cfg:
# zookeeper的數(shù)據(jù)存儲(chǔ)和日志存儲(chǔ)目錄(如果目錄不存在就新建) dataDir=/opt/zookeeper/data dataLogDir=/opt/zookeeper/log # zk集群之間的通信地址 server.1=192.168.100.142:2888:3888 server.2=192.168.100.143:2888:3888 server.3=192.168.100.144:2888:3888
創(chuàng)建/opt/zookeeper/data/myid文件,填入數(shù)字1:
# 由于該主機(jī)1(192.168.100.142)是server.1,所以在myid中設(shè)置數(shù)字1 $ vim /opt/zookeeper/data/myid
主機(jī)2(192.168.100.143):
/opt/zookeeper/conf/zoo.cfg:
dataDir=/opt/zookeeper/data dataLogDir=/opt/zookeeper/log server.1=192.168.100.142:2888:3888 server.2=192.168.100.143:2888:3888 server.3=192.168.100.144:2888:3888
創(chuàng)建/opt/zookeeper/data/myid文件,填入數(shù)字2:
# 由于該主機(jī)2(192.168.100.143)是server.2,所以在myid中設(shè)置數(shù)字2 $ vim /opt/zookeeper/data/myid
主機(jī)3(192.168.100.143):
/opt/zookeeper/conf/zoo.cfg:
dataDir=/opt/zookeeper/data dataLogDir=/opt/zookeeper/log server.1=192.168.100.142:2888:3888 server.2=192.168.100.143:2888:3888 server.3=192.168.100.144:2888:3888
創(chuàng)建/opt/zookeeper/data/myid文件,填入數(shù)字3:
# 由于該主機(jī)3(192.168.100.144)是server.3,所以在myid中設(shè)置數(shù)字3 $ vim /opt/zookeeper/data/myid1.2 分別啟動(dòng)zookeeper服務(wù)
$ /opt/zookeeper/bin/zkServer.sh start # 啟動(dòng)zk服務(wù) $ /opt/zookeeper/bin/zkServer.sh status # 查看zk服務(wù)狀態(tài)2. ActiveMQ集群 2.1 修改ActiveMQ配置文件conf/activemq.xml和conf/jetty.xml
主機(jī)IP | 服務(wù)端口(默認(rèn)) | 復(fù)制協(xié)議端口(動(dòng)態(tài)) | jetty控制臺(tái)端口(默認(rèn)) | 節(jié)點(diǎn)目錄/opt/下 | |
---|---|---|---|---|---|
192.168.100.142 | 61616 | tcp://0.0.0.0:0 | 8161 | activemq/node1 | |
192.168.100.143 | 61616 | tcp://0.0.0.0:0 | 8161 | activemq/node2 | |
192.168.100.144 | 61616 | tcp://0.0.0.0:0 | 8161 | activemq/node3 |
在3臺(tái)主機(jī)上都安裝activemq 服務(wù),/opt/activemq,并分別配置它們的文件conf/activemq.xml和conf/jetty.xml:
主機(jī)1(192.168.100.142):
/opt/activemq/conf/activemq.xml:
/opt/activemq/conf/jetty.xml:
主機(jī)2(192.168.100.143):
/opt/activemq/conf/activemq.xml:
/opt/activemq/conf/jetty.xml:
主機(jī)3(192.168.100.144):
/opt/activemq/conf/activemq.xml:
/opt/activemq/conf/jetty.xml:
2.2 依次啟動(dòng)activemq服務(wù)
$ /opt/activemq/bin/activemq start # 啟動(dòng)activemq服務(wù) $ ps -ef|grep activemq # 檢查進(jìn)程是否運(yùn)行,即activemq是否啟動(dòng)成功 $ netstat -anp|grep 61616 # 查看服務(wù)端口61616,監(jiān)聽情況三、Client使用
該zookeeper+activemq的集群Master Slave部署方案,能夠提供(3-1)/2的容錯(cuò)率,即3臺(tái)服務(wù)器允許宕機(jī)一臺(tái),而不影響整個(gè)集群的對(duì)外提供服務(wù)。
編寫代碼連接時(shí)使用failover策略:
String url = failover:(tcp://192.168.100.142:61616,tcp://192.168.100.143:61616,tcp://192.168.100.144:61616)?initialReconnectDelay=1000
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/69227.html
摘要:前言本案例使用的是偽集群方式,即在一臺(tái)主機(jī)上部署個(gè)服務(wù)端口不同個(gè)服務(wù)端口不同。要想保證負(fù)載均衡得再結(jié)合部署方案,配置網(wǎng)絡(luò)連接器。編碼時(shí),端消費(fèi)者通過協(xié)議來連接集群。只需使用進(jìn)行配置即可,默認(rèn)端口為。 前言 本案例使用的是偽集群方式,即在一臺(tái)主機(jī)上部署3個(gè)activemq服務(wù)(端口不同)+3個(gè)zookeeper服務(wù)(端口不同)。 真集群部署請看:ActiveMQ+ZooKeeper集群整...
摘要:二集群部署方式集群的部署方式主要有下面種模式實(shí)現(xiàn)負(fù)載均衡,多個(gè)之間同步消息,已達(dá)到服務(wù)器負(fù)載的可能。默認(rèn)為,單位為毫秒,表示一次嘗試重連之間等待的時(shí)間。如果宕機(jī),集群退化成標(biāo)準(zhǔn)集群,只是了失去負(fù)載均衡能力。 前言 最終需要掌握 Replicated LevelDB Store部署方式,這種部署方式是基于ZooKeeper的。 集群分為兩種方式:1.偽集群:集群節(jié)點(diǎn)都搭在一臺(tái)機(jī)器上2....
摘要:熱門框架學(xué)習(xí)目錄項(xiàng)目介紹專輯欄目一簡介環(huán)境安裝配置客戶端連接常用命令集群搭建分布式鎖二簡介環(huán)境安裝配置基本特性啟動(dòng)過程分析選舉過程主從數(shù)據(jù)同步過程分析集群搭建分布式鎖三簡介環(huán)境安裝配置基本特性基本概念和模型收發(fā)消息案例架構(gòu)初識(shí)收發(fā)消息原 HotFrameLearning 熱門框架學(xué)習(xí)(目錄) - I、項(xiàng)目介紹 - II、專輯欄目 一、Redis Redis 簡介 Redis 環(huán)境安裝...
摘要:主流消息中間件介紹是由出品,是一個(gè)完全支持和規(guī)范的實(shí)現(xiàn)。主流消息中間件介紹是阿里開源的消息中間件,目前也已經(jīng)孵化為頂級(jí)項(xiàng)目。 showImg(https://img-blog.csdnimg.cn/20190509221741422.gif);showImg(https://img-blog.csdnimg.cn/20190718204938932.png?x-oss-process=...
閱讀 750·2021-10-09 09:44
閱讀 2031·2021-09-22 15:54
閱讀 5069·2021-09-22 10:55
閱讀 1451·2019-08-29 18:41
閱讀 787·2019-08-29 11:24
閱讀 2114·2019-08-28 18:20
閱讀 1036·2019-08-26 11:51
閱讀 3057·2019-08-26 11:00