數(shù)據(jù)庫(kù)服務(wù)activemq在災(zāi)備雙活建設(shè)中有什么作用

這篇文章主要講解了“數(shù)據(jù)庫(kù)服務(wù)activemq在災(zāi)備雙活建設(shè)中有什么作用”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“數(shù)據(jù)庫(kù)服務(wù)activemq在災(zāi)備雙活建設(shè)中有什么作用”吧！

概述

activemq是業(yè)界非常流行的、功能強(qiáng)大的、開源消息中間件。以快速、支持多種跨語(yǔ)言客戶端和協(xié)議著稱；完全支持JMS 1.1 and J2EE 1.4。在各個(gè)行業(yè)中有大量的應(yīng)用案例。

由于activemq承擔(dān)著消息服務(wù)的重要角色，在這篇文章中我們重點(diǎn)講述在災(zāi)備雙活建設(shè)中activemq設(shè)計(jì)、規(guī)劃、部署。

目標(biāo)

災(zāi)備雙活建設(shè)最完美的架構(gòu)設(shè)計(jì)：在同城、異地2個(gè)數(shù)據(jù)中心，在最極端情況下，例如單數(shù)據(jù)中心垮掉情況下，保證消息零丟失，支持7*24服務(wù)要求。

需求描述

1.1 機(jī)房故障

1) 現(xiàn)象描述

消息隊(duì)列中間件部署在A、B兩個(gè)不同的機(jī)房中，客戶端根據(jù)負(fù)載的策略轉(zhuǎn)發(fā)到對(duì)應(yīng)機(jī)房的消息中間件，其中A或者B機(jī)房因?yàn)閿嚯娀蛘邽?zāi)難等因素出現(xiàn)故障，無法繼續(xù)提供服務(wù)。此時(shí)僅有一個(gè)機(jī)房正常。

2) 現(xiàn)象圖示

3) 服務(wù)影響

正常情況下，對(duì)于客戶端的連接平均分布在兩個(gè)機(jī)房中，出現(xiàn)單個(gè)機(jī)房故障后，連接在故障機(jī)房中的連接會(huì)斷開，正在執(zhí)行未提交的事務(wù)將會(huì)回滾，對(duì)于發(fā)起的新連接不受任何影響，依然可以通過配置的負(fù)載策略訪問正常機(jī)房中的消息中間件服務(wù)。

4) 故障恢復(fù)

當(dāng)機(jī)房恢復(fù)正常后，啟動(dòng)消息中間件服務(wù)，此時(shí)，只要主機(jī)、網(wǎng)絡(luò)恢復(fù)正常，消息中間件服務(wù)就可以啟動(dòng)成功。這時(shí)，AB機(jī)房按照負(fù)載策略繼續(xù)處理連接，最終使得每個(gè)機(jī)房的中間件連接數(shù)無限接近。

1.2 服務(wù)器DOWN

1) 現(xiàn)象描述

在運(yùn)行的消息中間件集群架構(gòu)中，存在N個(gè)主機(jī)，其中任意N-2個(gè)主機(jī)DOWN機(jī)，不具備服務(wù)提供能力，僅剩余大于1個(gè)主機(jī)存活可以提供服務(wù)的場(chǎng)景。

2) 現(xiàn)象圖示

3) 服務(wù)影響

主機(jī)DOWN掉后，已經(jīng)連接在該主機(jī)消息中間件上的連接會(huì)斷開，對(duì)應(yīng)的事務(wù)會(huì)回滾，新的連接不受到影響。

4) 故障恢復(fù)

當(dāng)主機(jī)故障處理后，啟動(dòng)故障主機(jī),并啟動(dòng)消息中間件服務(wù)。根據(jù)負(fù)載均衡算法，客戶端連接會(huì)重新分配到該主機(jī)上的節(jié)點(diǎn)。

1.3 消息中間件節(jié)點(diǎn)崩潰

1) 現(xiàn)象描述

在運(yùn)行的消息中間件集群架構(gòu)中，存在N個(gè)節(jié)點(diǎn)，其中任意N-2個(gè)節(jié)點(diǎn)崩潰，不具備服務(wù)提供能力，僅剩余大于1個(gè)節(jié)點(diǎn)存活可以提供服務(wù)的場(chǎng)景。

2) 現(xiàn)象圖示

3) 服務(wù)影響

當(dāng)消息中間件節(jié)點(diǎn)崩潰后，已經(jīng)連接在該主機(jī)消息中間件上的連接會(huì)斷開，對(duì)應(yīng)的事務(wù)會(huì)回滾，新的連接不受到影響。

4) 故障恢復(fù)

當(dāng)消息隊(duì)列節(jié)點(diǎn)故障處理后，啟動(dòng)消息中間件服務(wù)。根據(jù)負(fù)載均衡算法，客戶端連接會(huì)重新分配到該節(jié)點(diǎn)。

架構(gòu)設(shè)計(jì)

1.1 架構(gòu)設(shè)計(jì)要點(diǎn)

●、采用activemq的何種架構(gòu)來實(shí)現(xiàn)上述需求？

采用主從+Broker-Cluster方式來實(shí)現(xiàn)，主從架構(gòu)實(shí)現(xiàn)了HA（高可用）功能，借用zookeeper的選舉投票功能，保證“過半即可用”，所以推薦的HA架構(gòu)的節(jié)點(diǎn)數(shù)為單數(shù)，至少3個(gè)節(jié)點(diǎn)，任何時(shí)候垮掉一個(gè)節(jié)點(diǎn)都不影響正常使用。

同時(shí)結(jié)合Broker-Cluster，Broker-Cluster的部署方式可以解決負(fù)載均衡和分布式問題，因?yàn)閱我恢鲝姆绞綗o法解決負(fù)載均衡的問題。

●、如何保證未消費(fèi)消息在各個(gè)節(jié)點(diǎn)間的同步？

采用leveldb（LevelDB是Google開源的持久化KV單機(jī)數(shù)據(jù)庫(kù)，具有很高的隨機(jī)寫，順序讀/寫性能）實(shí)現(xiàn)各個(gè)節(jié)點(diǎn)間的同步寫，保證數(shù)據(jù)在同一個(gè)Broker-Cluster組下復(fù)制，以3個(gè)節(jié)點(diǎn)為例，同一條堆積消息，在3個(gè)節(jié)點(diǎn)保持同步，在最極端情況下，即使2個(gè)節(jié)點(diǎn)的數(shù)據(jù)文件丟失，也能防止數(shù)據(jù)丟失。

●、如何保證在災(zāi)難情況下，消息服務(wù)仍然可以正常提供服務(wù)？例如考慮最極端情況下，單邊數(shù)據(jù)中心宕機(jī)？

采用2套主從、2套Broker-Cluster，并且保證2個(gè)數(shù)據(jù)中心各包含一套主從的2個(gè)節(jié)點(diǎn)，如下圖所示，cluster1的2個(gè)節(jié)點(diǎn)在B中心，cluster2的2個(gè)節(jié)點(diǎn)在A中心，即使A、B整個(gè)數(shù)據(jù)中心發(fā)生災(zāi)難，都不影響jms服務(wù)正常運(yùn)行。

●、保證在各種災(zāi)難場(chǎng)景都實(shí)現(xiàn)了7*24和消息零丟失嗎？

是的，只要保證一個(gè)cluster下的2個(gè)節(jié)點(diǎn)可用的情況下，不管在任何一種組合下，jms服務(wù)都是可用的。

●、客戶端如何來調(diào)用集群的jms地址

connectionFactory = new ActiveMQConnectionFactory(

ActiveMQConnection.DEFAULT_USER,

ActiveMQConnection.DEFAULT_PASSWORD,

                    "failover:(tcp://192.168.40.140:61616,tcp://192.168.40.140:61617,tcp://192.168.40.141:61619,tcp://192.168.40.141:61620,tcp://192.168.40.141:61621,tcp://192.168.40.140:61618)");

如上例子，activemq根據(jù)隨機(jī)策略，調(diào)用任一可用的節(jié)點(diǎn)

1.2 架構(gòu)圖示

●、架構(gòu)示例圖如下：

◆、哪一個(gè)節(jié)點(diǎn)是master，沒有要求，那個(gè)先啟動(dòng)那個(gè)就可能成為master。

◆、master節(jié)點(diǎn)是當(dāng)前提供服務(wù)的節(jié)點(diǎn)。

感謝各位的閱讀，以上就是“數(shù)據(jù)庫(kù)服務(wù)activemq在災(zāi)備雙活建設(shè)中有什么作用”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)數(shù)據(jù)庫(kù)服務(wù)activemq在災(zāi)備雙活建設(shè)中有什么作用這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！