【ActiveMQ中文指南】第五章

2.5 Clustering
ActiveMQ從多種不同的方面提供了集群的支持。
2.5.1 Queue consumer clusters
ActiveMQ支持訂閱同一個queue的consumers上的集群。如果一個consumer失效,那么所有未被確認(unacknowledged)的消息都會被發送到這個queue上其它的consumers。如果某個consumer的處理速度比其它consumers更快,那么這個consumer就會消費更多的消息。
需要注意的是,筆者發現AcitveMQ5.0版本的Queue consumer clusters存在一個bug:采用AMQ Message Store,運行一個producer,兩個consumer,并采用如下的配置文件:

Xml代碼 ?收藏代碼
  1. <beans>
  2. ??<broker?xmlns=“http://activemq.org/config/1.0″?brokerName=“BugBroker1″?useJmx=“true”>
  3. ????<transportConnectors>
  4. ??????<transportConnector?uri=“tcp://localhost:61616″/>
  5. ????</transportConnectors>
  6. ????<persistenceAdapter>
  7. ??????<amqPersistenceAdapter?directory=“activemq-data/BugBroker1″?maxFileLength=“32mb”/>
  8. ????</persistenceAdapter>
  9. ??</broker>
  10. </beans>

那么經過一段時間后可能會報出如下錯誤:
ERROR [ActiveMQ Transport: tcp:///127.0.0.1:1843 – RecoveryListenerAdapter.java:58 – RecoveryListenerAdapter] Message id ID:versus-1837-1203915536609-0:2:1:1:419 could not be recovered from the data store!
Apache官方文檔說,此bug已經被修正,預定在5.1.0版本上體現。

 

2.5.2 Broker clusters
一個常見的場景是有多個JMS broker,有一個客戶連接到其中一個broker。如果這個broker失效,那么客戶會自動重新連接到其它的broker。在ActiveMQ中使用failover:// 協議來實現這個功能。ActiveMQ3.x版本的reliable://協議已經變更為failover://。
如果某個網絡上有多個brokers而且客戶使用靜態發現(使用Static Transport或Failover Transport)或動態發現(使用Discovery Transport),那么客戶可以容易地在某個broker失效的情況下切換到其它的brokers。然而,stand alone brokers并不了解其它brokers上的consumers,也就是說如果某個broker上沒有consumers,那么這個broker上的消息可能會因得不到處理而積壓起來。目前的解決方案是使用Network of brokers,以便在broker之間存儲轉發消息。ActiveMQ在未來會有更好的特性,用來在客戶端處理這個問題。
從ActiveMQ1.1版本起,ActiveMQ支持networks of brokers。它支持分布式的queues和topics。一個broker會相同對待所有的訂閱(subscription):不管他們是來自本地的客戶連接,還是來自遠程broker,它都會遞送有關的消息拷貝到每個訂閱。遠程broker得到這個消息拷貝后,會依次把它遞送到其內部的本地連接上。有兩種方式配置Network of brokers,一種是使用static transport,如下:

Xml代碼 ?收藏代碼
  1. <broker?brokerName=“receiver”?persistent=“false”?useJmx=“false”>
  2. ??<transportConnectors>
  3. ????<transportConnector?uri=“tcp://localhost:62002″/>
  4. ??</transportConnectors>
  5. ??<networkConnectors>
  6. ????<networkConnector?uri=“static:(?tcp://localhost:61616,tcp://remotehost:61616)”/>
  7. ??</networkConnectors>
  8. ??…
  9. </broker>

另外一種是使用multicast discovery,如下:

Xml代碼 ?收藏代碼
  1. <broker?name=“sender”?persistent=“false”?useJmx=“false”>
  2. ??<transportConnectors>
  3. ????<transportConnector?uri=“tcp://localhost:0″?discoveryUri=“multicast://default”/>
  4. ??</transportConnectors>
  5. ??<networkConnectors>
  6. ????<networkConnector?uri=“multicast://default”/>
  7. ??</networkConnectors>
  8. ??…
  9. </broker>

Network Connector有以下屬性:

Property Default Value Description
name bridge name of the network – for more than one network connector between the same two brokers – use different names
dynamicOnly false if true, only forward messages if a consumer is active on the connected broker
decreaseNetworkConsumerPriority false decrease the priority for dispatching to a Queue consumer the further away it is (in network hops) from the producer
networkTTL 1 the number of brokers in the network that messages and subscriptions can pass through
conduitSubscriptions true multiple consumers subscribing to the same destination are treated as one consumer by the network
excludedDestinations empty destinations matching this list won’t be forwarded across the network
dynamicallyIncludedDestinations empty destinations that match this list will be forwarded across the network n.b. an empty list means all destinations not in the excluded list will be forwarded
staticallyIncludedDestinations empty destinations that match will always be passed across the network – even if no consumers have ever registered an interest
duplex false if true, a network connection will be used to both produce AND Consume messages. This is useful for hub and spoke scenarios when the hub is behind a firewall etc.

關于conduitSubscriptions屬性,這里稍稍說明一下。設想有兩個brokers,分別是brokerA和brokerB,它們之間用forwarding bridge連接。有一個consumer連接到brokerA并訂閱queue:Q.TEST。有兩個consumers連接到brokerB,也是訂閱queue:Q.TEST。這三個consumers有相同的優先級。然后啟動一個producer,它發送了30條消息到brokerA。如果conduitSubscriptions=true,那么brokerA上的consumer會得到15條消息, 另外15條消息會發送給brokerB。此時負載并不均衡,因為此時brokerA將brokerB上的兩個consumers視為一個;如果conduitSubscriptions=false,那么每個consumer上都會收到10條消息。以下是關于NetworkConnector屬性的一個例子:

Xml代碼 ?收藏代碼
  1. <networkConnectors>
  2. ??<networkConnector?uri=“static://(tcp://localhost:61617)”
  3. ?????name=“bridge”?dynamicOnly=“false”?conduitSubscriptions=“true”
  4. ?????decreaseNetworkConsumerPriority=“false”>
  5. ?????<excludedDestinations>
  6. ???????<queue?physicalName=“exclude.test.foo”/>
  7. ???????<topic?physicalName=“exclude.test.bar”/>
  8. ?????</excludedDestinations>
  9. ?????<dynamicallyIncludedDestinations>
  10. ???????<queue?physicalName=“include.test.foo”/>
  11. ???????<topic?physicalName=“include.test.bar”/>
  12. ?????</dynamicallyIncludedDestinations>
  13. ?????<staticallyIncludedDestinations>
  14. ???????<queue?physicalName=“always.include.queue”/>
  15. ???????<topic?physicalName=“always.include.topic”/>
  16. ?????</staticallyIncludedDestinations>
  17. ??</networkConnector>
  18. </networkConnectors>

 

2.5.3 Master Slave
在一個網絡內運行多個brokers或者stand alone brokers時存在一個問題,這就是消息在物理上只被一個broker持有,因此當某個broker失效,那么你只能等待直到它重啟后,這個broker上的消息才能夠被繼續發送(如果沒有設置持久化,那么在這種情況下,消息將會丟失)。Master Slave 背后的想法是,消息被復制到slave broker,因此即使master broker遇到了像硬件故障之類的錯誤,你也可以立即切換到slave broker而不丟失任何消息。
Master Slave是目前ActiveMQ推薦的高可靠性和容錯的解決方案。以下是幾種不同的類型:

Master Slave Type Requirements Pros Cons
Pure Master Slave None No central point of failure Requires manual restart to bring back a failed master and can only support 1 slave
Shared File System Master Slave A Shared File system such as a SAN Run as many slaves as required. Automatic recovery of old masters Requires shared file system
JDBC Master Slave A Shared database Run as many slaves as required. Automatic recovery of old masters Requires a shared database. Also relatively slow as it cannot use the high performance journal

 

2.5.3.1 Pure Master Slave
Pure Master Slave的工作方式如下:

  • Slave broker消費master broker上所有的消息狀態,例如消息、確認和事務狀態等。只要slave broker連接到了master broker,它不會(也不被允許)啟動任何network connectors或者transport connectors,所以唯一的目的就是復制master broker的狀態。
  • Master broker只有在消息成功被復制到slave broker之后才會響應客戶。例如,客戶的commit請求只有在master broker和slave broker都處理完畢commit請求之后才會結束。
  • 當master broker失效的時候,slave broker有兩種選擇,一種是slave broker啟動所有的network connectors和transport connectors,這允許客戶端切換到slave broker;另外一種是slave broker停止。這種情況下,slave broker只是復制了master broker的狀態。
  • 客戶應該使用failover transport并且應該首先嘗試連接master broker。例如:
    failover://(tcp://masterhost:61616,tcp://slavehost:61616)?randomize=false
    設置randomize為false就可以讓客戶總是首先嘗試連接master broker(slave broker并不會接受任何連接,直到它成為了master broker)。

Pure Master Slave具有以下限制:

  • 只能有一個slave broker連接到master broker。
  • 在因master broker失效而導致slave broker成為master之后,之前的master broker只有在當前的master broker(原slave broker)停止后才能重新生效。
  • Master broker失效后而切換到slave broker后,最安全的恢復master broker的方式是人工處理。首先要停止slave broker(這意味著所有的客戶也要停止)。然后把slave broker的數據目錄中所有的數據拷貝到master broker的數據目錄中。然后重啟master broker和slave broker。

Master broker不需要特殊的配置。Slave broker需要進行以下配置

Xml代碼 ?收藏代碼
  1. <broker?masterConnectorURI=“tcp://masterhost:62001″?shutdownOnMasterFailure=“false”>
  2. ????…
  3. ????<transportConnectors>
  4. ??????<transportConnector?uri=“tcp://slavehost:61616″/>
  5. ???</transportConnectors>
  6. </broker>

其中的masterConnectorURI用于指向master broker,shutdownOnMasterFailure用于指定slave broker在master broker失效的時候是否需要停止。此外,也可以使用如下配置:

Xml代碼 ?收藏代碼
  1. <broker?brokerName=“slave”?useJmx=“false”??deleteAllMessagesOnStartup=“true”??xmlns=“http://activemq.org/config/1.0″>
  2. ??…
  3. ??<services>
  4. ????<masterConnector?remoteURI=?“tcp://localhost:62001″?userName=“user”?password=“password”/>
  5. ??</services>
  6. </broker>

需要注意的是,筆者認為ActiveMQ5.0版本的Pure Master Slave仍然不夠穩定。

 

2.5.3.2 Shared File System Master Slave
如果你使用SAN或者共享文件系統,那么你可以使用Shared File System Master Slave。基本上,你可以運行多個broker,這些broker共享數據目錄。當第一個broker得到文件上的排他鎖之后,其它的broker便會在循環中等待獲得這把鎖。客戶端使用failover transport來連接到可用的broker。當master broker失效的時候會釋放這把鎖,這時候其中一個slave broker會得到這把鎖從而成為master broker。以下是ActiveMQ配置的一個例子:

Xml代碼 ?收藏代碼
  1. <broker?useJmx=“false”??xmlns=“http://activemq.org/config/1.0″>
  2. ???<persistenceAdapter>
  3. ??????<journaledJDBC?dataDirectory=“/sharedFileSystem/broker”/>
  4. ???</persistenceAdapter>
  5. ???…
  6. </broker>

 

2.5.3.3 JDBC Master Slave
JDBC Master Slave的工作原理跟Shared File System Master Slave類似,只是采用了數據庫作為持久化存儲。以下是ActiveMQ配置的一個例子:

Xml代碼 ?收藏代碼
  1. <beans>
  2. ??<broker?xmlns=“http://activemq.org/config/1.0″?brokerName=“JdbcMasterBroker”>
  3. ????…
  4. ????<persistenceAdapter>
  5. ??????<jdbcPersistenceAdapter?dataSource=“#mysql-ds”/>
  6. ????</persistenceAdapter>
  7. ??</broker>
  8. ??<bean?id=“mysql-ds”?class=“org.apache.commons.dbcp.BasicDataSource”?destroy-method=“close”>
  9. ????<property?name=“driverClassName”?value=“com.mysql.jdbc.Driver”/>
  10. ????<property?name=“url”?value=“jdbc:mysql://localhost:3306/test?relaxAutoCommit=true”/>
  11. ????<property?name=“username”?value=“username”/>
  12. ????<property?name=“password”?value=“passward”/>
  13. ????<property?name=“poolPreparedStatements”?value=“true”/>
  14. ??</bean>
  15. </beans>

需要注意的是,如果你使用MySQL數據庫,需要首先執行以下三條語句:(Apache官方文檔說,此bug已經被修正,預定在5.1.0版本上體現)

Sql代碼 ?收藏代碼
  1. ALTER?TABLE?activemq_acks?ENGINE?=?InnoDB;
  2. ALTER?TABLE?activemq_lock?ENGINE?=?InnoDB;
  3. ALTER?TABLE?activemq_msgs?ENGINE?=?InnoDB;
本站部分文章源于互聯網,本著傳播知識、有益學習和研究的目的進行的轉載,為網友免費提供。如有著作權人或出版方提出異議,本站將立即刪除。如果您對文章轉載有任何疑問請告之我們,以便我們及時糾正。

PS:推薦一個微信公眾號: askHarries 或者qq群:474807195,里面會分享一些資深架構師錄制的視頻錄像:有Spring,MyBatis,Netty源碼分析,高并發、高性能、分布式、微服務架構的原理,JVM性能優化這些成為架構師必備的知識體系。還能領取免費的學習資源,目前受益良多

轉載請注明原文出處:Harries Blog? » 【ActiveMQ中文指南】第五章

贊 (0)
分享到:更多 ()

評論 1

  • 昵稱 (必填)
  • 郵箱 (必填)
  • 網址
  1. 漂泊一劍客博主,你好,請問不同的Broker之間需要同步一些什么信息?回復
2013平特肖公式