解決單點故障：JDBC Master Slave

3.1     概述

1.         配置上，不存在Master和Slave，所有Broder的配置基本是一樣的

2.         多個共享資料源的Broker構成JDBC Master Slave

3.         給每個Broker取個名字

4.         首先搶到資源（資料庫鎖）的Broker成為Masetr

5.         其他Broker保持預備狀态，定期嘗試搶占資源，運作其的Shell中清楚的顯示了這一點

6.         一旦Master崩潰，其他Broker嘗試搶占資源，最終隻有一台搶到，它立刻成為Master

7.         之前的Master即使重新開機成功，也隻能作為Slave等待

3.2     MQ配置（這裡是一台機器配置）

1.         将 $activemq_dir$/conf/activemq.xml 複制3份，分别改名為：jdbc_broker01.xml、jdbc_broker02.xml、jdbc_broker03.xml

2.         首先修改jdbc_broker01.xml

1)         <broker brokerName=" jdbc_broker01" …

2)         <!--配置持久擴充卡-->

<persistenceAdapter>

<jdbcPersistenceAdapter dataDirectory="${activemq.base}/data"

dataSource="#mysql-ds"/>

</persistenceAdapter>

3)         <transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/>

4)         <!--配置資料源：注意是在broker标記之外-->

…

</broker>

<bean id="mysql-ds" class="org.apache.commons.dbcp.BasicDataSource"

destroy-method="close">

<property name="driverClassName" value="com.mysql.jdbc.Driver"/>

<property name="url"

value="jdbc:mysql://localhost/test?relaxAutoCommit=true"/>

<property name="username" value="root"/>

<property name="password" value="root"/>

<property name="maxActive" value="200"/>

<property name="poolPreparedStatements" value="true"/>

</bean>

3.         同樣修改 jdbc_broker02.xml ，與 jdbc_broker01.xml 不同之處

1)         <broker brokerName=" jdbc_broker02" …

2)         <transportConnector name="openwire" uri="tcp://0.0.0.0:61617"/>

4.         同樣修改 jdbc_broker03.xml ，與 jdbc_broker01.xml 不同之處

1)         <broker brokerName=" jdbc_broker03" …

2)         <transportConnector name="openwire" uri="tcp://0.0.0.0:61618"/>

3.3     JAVA測試：隊列

1.         代碼基本和前面一緻，隻是因為這裡有3個broker，是以建立連接配接工廠的代碼稍有差别：

ConnectionFactory cf = new ActiveMQConnectionFactory("failover:(tcp://0.0.0.0:61616,tcp://0.0.0.0:61617,tcp://0.0.0.0:61618)");

3.4     測試步驟

1.         先啟動生産者，發送幾條消息

2.         啟動消費者，可看到接收到的消息

3.         關閉消費者

4.         生産者繼續發送幾條消息-消息A

5.         停止broker01（可看到生産者端顯示連接配接到broker02（tcp://0.0.0.0:61617）了，同時運作broker02的Shell也顯示其成為了Master）

6.         生産者繼續發送幾條消息-消息B

7.         啟動消費者

8.         消費者接收了消息A和消息B，可見broker02接替了broker01的工作，而且儲存了之前生産者經過broker01發送的消息

9.         關閉消費者

10.     生産者繼續發送幾條消息-消息C

11.     停止broker02（可看到生産者端顯示連接配接到broker03（tcp://0.0.0.0:61618）了，同時運作broker03的Shell也顯示其成為了Master）

12.     生産者繼續發送幾條消息-消息D

13.     啟動消費者

14.     消費者接收了消息C和消息D，可見broker03接替了broker02的工作，而且儲存了之前生産者經過broker02發送的消息

15.     再次啟動broker01，生産者或消費者均未顯示連接配接到broker01(tcp://0.0.0.0:61616)，表明broker01此時隻是個Slave

3.5     結論

JDBC Master Slave模式實作方式稍微複雜一點，可以實作消息的多點熱備功能，Master、Slave的交替完全是即時的，自動的，無需重新開機任何broker；隊列可以實作消息的異步和點對點發送