ActiveMQ學習筆記02 - 多服務器間的通訊

ActiveMQ支持多服務器(Broker)之間的網絡鏈接，也就是集羣。經過集羣多個ActiveMQ Broker的實例，提供一個對外的統一服務，用來提升ActiveMQ的可用性和擴展性。

服務器之間的通訊，按照通訊方式能夠分爲兩種，橋接轉發(Bridge Forwarding)和雙向傳輸(duplex)。顧名思義，橋接轉發是將消息傳遞給另一個ActiveMQ的Broker，雙向傳輸是用一個通道既能夠收消息，也能夠發消息。

按照發現Broker的方式來區分，也能夠分紅另外兩種，靜態註冊和動態發現。若是你確切的知道每一臺Broker的地址和端口號，那麼可使用靜態註冊的方式；若是你並不知道每一臺Broker的狀況，好比，一個可動態擴展的生產環境，那麼動態發現方式將很是合適。

每一種通訊方式，一樣是經過編輯%ACTIVEMQ_HOME%conf\activemq.xml文件來完成配置。以下：

<networkConnectors>
    <networkConnector name="default-nc" uri="multicast://default"/> 
</networkConnectors>

在networkConnectors的節點下能夠配置多個networkConnector，每一個networkConnector是一種Broker-to-Broker的通訊方式。下面具體介紹一下ActiveMQ支持的Broker-to-Broker的幾種協議。

靜態註冊：

服務器端的Static Connector：被設置爲Static Connector的兩個Broker之間會轉發消息，發給BrokerA的消息，會轉發給BrokerB。但不是實時轉發，而是在Consumer訪問BrokerB的時候再轉發。配置以下：

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="BrokerB" dataDirectory="${activemq.base}/data">
    <transportConnectors>
        <transportConnector name="openwire" uri="tcp://localhost:61616" /> 
    </transportConnectors> 
    <networkConnectors>
        <networkConnector uri="static:(tcp://remotehost:61616)" /> 
    </networkConnectors>
</broker>

這樣，發給remotehost的消息，會在Consumer從localhost中取消息的時候自動轉發過去。

Static Connector比較適合用在須要分散Consumer鏈接的場景。好比：有一個Broker有不少Consumer，並且每一個Consumer在不一樣的地區。若是每一個Consumer都鏈接同一個Broker，那麼這個Broker將維護大量的鏈接，若是每一個地區一個Broker，則每一個地區的Consumer只須要鏈接本地的Broker。Broker之間經過Static自動轉發消息，能夠緩解單臺Broker鏈接過多的問題。

在實際測試的時候發現了《ActiveMQ in Action》書中有一點沒寫清楚。只有Queue纔是Consumer消費的時候轉發消息。持久化Topic是同步轉發消息的，而且remotehost上面的消息都會被標記爲已消費。

客戶端的Failover Protocol：顧名思義，這個協議是失效轉移。客戶端會默認使用隨機算法選擇事先配置好的幾個Broker之一；也能夠關閉隨機選擇。若是被選中的Broker發生情況，致使不能提供服務，客戶端會選擇另外一個可用的Broker，若是某個Broker不可用，ActiveMQ會無限制的重試。(每次鏈接重試的延遲時間可配置)

默認配置，使用隨機選擇Broker算法：

failover:(tcp://localhost:61616，tcp://remotehost:61616)

關閉隨機選擇，優先選擇第一個配置的Broker，只有以前的Broker不可用，再選擇後面Broker：

failover:(tcp://localhost:61616,tcp://remotehost:61616)?randomize=false"

因爲自動重連機制，因此強烈推薦客戶端使用faliover，即便是隻有一個Broker，也能夠經過自動重連功能，在Broker從新啓動以後從新建立鏈接，而不用手動重啓客戶端。這樣能夠提高程序的健壯性。

注意這個failover和static是不一樣的，static鏈接是用於服務器端自動轉移消息，客戶端並不知道服務器端是怎麼轉移消息的，也不知道到底服務器是幾個，對客戶端是徹底透明的。failover是客戶端失效轉移，客戶端鏈接服務器的的url須要明確的指出，因此客戶端必須知道服務器端的網絡拓撲結構。

動態發現：

服務器端的Multicast Connector：服務器之間經過廣播功能自動發現其餘服務器。每一個服務器都會把本身的服務發佈給224.0.0.0 - 239.255.255.255 IP地址段，也會從這個地址段找尋其餘服務器。這樣多個服務器之間能夠主動的相互發現。配置以下：

<broker xmlns="http://activemq.apache.org/schema/core" brokerName="multicast" dataDirectory="${activemq.base}/data">
    <networkConnectors>
        <networkConnector name="default-nc" uri="multicast://default"/> 
    </networkConnectors>
    <transportConnectors> 
        <transportConnector name="openwire" uri="tcp://localhost:61616" discoveryUri="multicast://default"/>
    </transportConnectors>
</broker>

在networkConnectors節點中配置multicast協議，用於尋找其餘支持multicast的服務器。在transportConnector節點配置discoveryUri，聲明服務器自己支持multicast協議。

廣播自動發現服務器，適合於常常動態增減服務器的狀況。優勢是增減服務器，不須要爲每一個其餘服務器節點修改配置。缺點是服務自動發現，缺乏配置文件，對調試有影響。另外須要注意的是，因爲廣播功能，常常產生大量的消息傳輸，因此不少狀況下運維是關掉這個服務的。使用Multicast Connector前要確保這個服務是開啓的。

客戶端的Discover Protocol：和Failover Protocol差很少，只不過是動態發現服務。配置以下：

discovery:(multicast://default)

這樣客戶端會自動鏈接廣播的url在multicast://default的服務器。

客戶端的Fanout Protocol：扇出協議，用於一個客戶端同時向多個服務器發一樣的消息。

靜態查找配置以下：

fanout:(static:(tcp://host1:61616,tcp://host2:61616,tcp://host3:61616))

固然也能夠支持動態發現：

fanout:(multicast://default)

這個適用場景不多，畢竟客戶端直接控制發冗餘消息給服務器，實際上將變得更加不可控，不建議使用。

客戶端的Peer Protocol：對等協議，用於前嵌入式服務器的鏈接，使用場景較少。