ActiveMQ（七）——ActiveMQ的Network

1、在一臺服務器上啓動多個Broker

• 步驟以下（爲集羣作準備）：
  1：把整個conf文件夾複製一份，好比叫作conf2
  2：修改裏面的activemq.xml文件
  （1）裏面的brokerName不能跟原來的重複
  （2）數據存放的文件名稱不能重複，好比：
  <hahaDB directory=」${activemq.data}/kahadb_2」/>
  （3）全部設計的transportConnectors的端口，都要跟前面的不同
  3：修改jetty.xml，主要就是修改端口，好比：
  <property name=」port」 value=」8181」/>端口必須和前面的不同
  4：到bin下面，複製一個activemq，好比叫作activemq2；
  （1）修改程序的id，不能和前面的重複
  ACTIVEMQ_PIDFILE=」$ACTIVEMQ_DATA/activemq2-hostname.pid」
  （2）修改配置文件路徑
  ACTIVEMQ_CONF=」$ACTIVEMQ_BASE/conf2」
  （3）修改端口，裏面有個tcp的61616的端口，要改爲不同的，最好跟 activemq.xml裏面的ctp的端口一致
  （4）而後就能夠執行了。

2、ActiveMQ的靜態網絡連接

• ActiveMQ的networkConnector是什麼
  在某些場景下，須要多個ActiveMQ的Broker作集羣，那麼久涉及到Broker的通訊，這個被稱爲ActiveMQ的networkConnector。
      ActiveMQ的networkConnector默認是單向的，一個Broker在一端發送消息，另外一個Broker在另外一端接收消息。這就是所謂的「橋接」。ActiveMQ也支持雙向連接，建立一個雙向的通道對於兩個Broker，不只發送消息並且也能從相同的通道來接收消息，一般做爲duplex connector來映射，以下：
  
• 「discovery」的概念
      通常狀況下，discovery是被用來發現遠程的服務，客戶端一般想去發現全部可利用的brokers；另外一層意思，它是基於現有的網絡Broker去發現其餘可用的Brokers。
      有兩種配置Client到Broker的連接方式，一種方式：Client經過Statically配置的方式去鏈接Broker，另外一種方式：Client經過discovery agents來dynamically發現Brokers
• Static networks
      Static networkConnector是用於建立一個靜態的配置對於網絡中的多個Broker。這種協議用於複合url，一個複合url包括多個url地址。格式以下：
  static:(uri1,uri2,uri3,...)?Key=value
  1：配置示例以下（activemq.xml--註釋掉persistenceFactory節點）：

  <networkConnectors>
  <networkConnector name="local network" uri="static://(tcp://remotehost1:61616,tcp://remotehost2:61616)"/>
  </networkConnectors>

• Static networkConnector的基本原來示意圖：
  
      上圖中，兩個Brokers是經過一個static的協議來網絡連接的。一個Consumer連接到BrokerB的一個地址上，當Producer在BrokerA上以相同的地址發送消息時，此時它將被轉移到BrokerB上。也就是，BrokerA會轉發消息到BrokerB上。
• networkConnector配置的可用屬性
  一、name：默認是bridge
  二、dynamicOnly：默認是false，若是爲true，持久訂閱被激活時才建立對應的網絡持久訂閱。默認是啓動時激活
  三、decreaseNetworkConsumerPriority：默認是false。設定消費者優先權，若是爲true，網絡的消費者優先級下降爲-5。若是爲false，則默認跟本地消費者同樣爲0
  四、networkTTL：默認是1，網絡中用於消息和訂閱消費的broker數量
  五、messageTTL：默認是1，網絡中用於消息的broker數量
  六、consumerTTL：默認是1，網絡中用於消費的broker數量
  七、conduitSubscriptions：默認true，是否把同一個broker的多個consumer當作一個來處理
  八、dynamicallyIncludedDestinations：默認爲空，要包括的動態消息地址，相似於excludedDestinations,如

  <dynamicallyIncludedDestinations>
  <queue physicalName="include.test.foo"/>
  <topic physicalName="include.test.bar"/>
  </dynamicallyIncludedDestinations>

  九、staticallyIncludedDestinations：默認爲空，要包括的靜態消息地址。相似於excludedDestinations，如：

  <staticallyIncludedDestinations>
  <queue physicalName="always.include.queue"/>
  </staticallyIncludedDestinations>

  十、excludedDestinations：默認爲空，指定排除的地址，示例以下：
  
  十一、duplex：默認false，設置是否能雙向通訊
  十二、prefetchSize：默認是1000，持有的未確認的最大消息數量，必須大於0，由於網絡消費者不能本身輪詢消息
  1三、suppressDuplicateQueueSubscriptions：默認false，若是爲true，重複的訂閱關係一產生即被阻止
  1四、bridgeTempDestinations：默認true，是否廣播advisory messages來建立臨時destination
  1五、alwaysSyncSend：默認false，若是爲true，非持久化消息也將使用request/reply方式代替oneway方式發送到遠程broker
  1六、staticBridge：默認false，若是爲true，只有staticallyIncludedDestinations中配置的destination能夠被處理

3、「丟失」的消息
     存在這樣的場景，broker1和broker2經過networkConnector鏈接，一些consumers鏈接到broker1，消費broker2上的消息。消息先被broker1從broke2上消費掉，而後轉發給這些consumers。不幸的是轉發部分消息的時候broker1重啓了，這些consumers發現broker1鏈接失敗，經過failover鏈接到broker2上去了，可是又一部分他們尚未消費的消息被broker2已經分發到broker1上去了。這些消息，就好像是消失了，除非有消費者從新鏈接到broker1上來消費。
     從5.6版起，在destinationPolicy上新增的選項replayWhenNoConsumers。這個選項使得broker1上有須要轉發的消息可是沒有消費者時，把消息迴流到它原始的broker。同時把enableAudit設置爲false，爲了防止消息迴流後被當作重複消息而不被分發，示例以下：

<destinationPolicy>
    <policyMap>
        <policyEntry queue=">" enableAudit="false">
            <networkBridgeFilterFactory>
                <conditionalNetworkBridgeFilterFactory replayWhenNoConsumers="true"/>
            </networkBridgeFilterFactory>
        </policyEntry>
    </policyMap>
</destinationPolicy>

4、容錯的鏈接

• Failover Protocol
      以前的都是Client配置連接到指定的broker上。可是，若是Broker的連接失敗怎麼辦？此時，Client有兩個選項：要麼馬上死掉，要麼去鏈接到其它的broker上。
      Failover協議實現了自動從新連接的邏輯。這裏有兩種方式提供了穩定的brokers列表對於Client連接。
  第一種：提供一個static的可用的Brokers列表
  第二種：提供一個dynamic發現的可用Brokers
• Failover Protocol的默認方式
  failover:(uri1,...,uriN)?key=value或者failover:uri1,...,uriN
  & Failover Protocol的默認配置
  默認狀況下，這種協議用於隨機的去選擇一個連接去連接，若是連接失敗了，那麼會連接到其它的Broker上。默認的配置定義了延遲從新連接，意味着傳輸將會在10秒後自動的去從新連接可用的broker。全部的從新連接參數都是能夠根據應用的須要而配置的。
• Failover Protocol的使用示例，在客戶端程序裏面

  ConnectionFactory connectionFactory = new ActiveMQConnectionFactory   ("failover:(tcp://localhost:61616,tcp://localhost:61617)
  ?randomize=false");

• Failover Protocol可用的配置參數：
  一、initialReconnectDelay：第一次嘗試重連以前等待的時間（毫秒）默認10
  二、maxReconnectDelay：最長重連的時間間隔（毫秒），默認30000
  三、useExponentialBackOff：重連時間間隔是否以指數形式增加，默認true
  四、backOffMultiplier：遞增倍數，默認2.0
  五、maxReconnectAttempts：默認-1|0，自版本5.6起，-1爲默認值，表明不限重連次數；0表明從不重試（只嘗試鏈接一次，並不重連），5.6版本以前，0爲默認值，表明不限重試次數；大於0的數，表明最大重試次數。
  六、startupMaxReconnectAttempts：初始化時的最大重連次數。一旦鏈接上，將使用maxReconnectAttempts的配置，默認0
  七、Randomize：使用隨機鏈接，以達到負載均衡的目的，默認true
  八、Backup：提早初始化一個未使用鏈接，以便進行快速失敗轉移，默認false
  九、timeout：設置發送操做的超時時間（毫秒），默認-1
  十、trackMessages：設置是否緩存[故障發生時]還沒有傳送完成的消息，當broker一旦從新鏈接成功，便將這些緩存中的消息刷新到新鏈接的代理中，使得消息能夠在broker切換先後順序傳送，默認false
  十一、maxCacheSize：當trackMessages啓用時，緩存的最大字節，默認爲128*1024 字節
  十二、updateURIsSupported：設定是否能夠動態修改broker rui（自版本5.4起），默認true

5、動態網絡鏈接（純理論）
多播協議multicast
    ActiveMQ使用Multicast協議將一個Service和其餘的Broker的Service鏈接起來。IP multicast是一個被用於網絡中傳輸數據到其餘一組接收者的技術。
    IP multicast傳統的概念成爲組地址。組地址是ip地址在224.0.0.0到239.255.255.255之間的ip地址。ActiveMQ broker使用multicast協議去創建服務與遠程的broker的服務的網絡鏈接。

• 基本的格式配置
  multicast://ip address:port?transportOptions
  一、group：表示惟一的組名稱，缺省值default
  二、minmumWireFormatVersion：被容許的最小的wireformat版本，缺省爲0
  三、trace：是否追蹤記錄日誌，默認false
  四、useLocalHost：表示本地機器的名稱是否爲localhost，默認true
  五、datagramSize：特定的數據大小，默認值41024
  六、timeToLive：消息的聲明週期值，默認值-1
  七、loopBackMode：是否啓用loopback模式，默認false
  八、wireFormat：默認用wireFormat命名
  九、wireFormat.：前綴是wireFormat

• 配置示例
  1：默認配置，默認狀況下是不可靠的多播，數據包可能會丟失
  multicast://default
  2：特定的ip和端口
  multicast://224.1.2.3:6255
  3：特定的ip和端口以及組名
  multicast://224.1.2.3:6255?group=mygroupname

• ActiveMQ使用multicast協議的配置格式以下：

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

  說明：
  1：uri="multicast://default"中的default是activemq默認的ip，默認動態 的尋找地址
  2："discoveryUri"是指在transport中用multicast的default的地址傳遞
  3："uri"指動態尋找可利用的地址
  4：若是防止自動的尋找地址？
  （1）名稱爲openwire的transport，移除discoveryUri="multicast:
  //default"便可。傳輸鏈接用默認的名稱openwire來配置broker的tcp多點鏈接，這將容許其餘broker可以自動發現和鏈接到可用的broker中。
  （2）名稱爲"default-nc"的networkConnector，註釋掉或者刪除便可。
  ActiveMQ默認的networkConnector基於multicast協議的鏈接的默認名稱是default-nc，並且自動的去發現其餘broker。去中止這種行爲，只須要註銷或者刪除掉default-nc網絡鏈接。
  （3）使brokerName的名字惟一，能夠惟一識別Broker的實例，默認是localhost

• multicast協議和普通的tcp協議
  它們是差很少的，不一樣的是multicast可以自動的發現其餘broker，從而替代了使用static功能列表brokers。用multicast協議能夠在網絡中頻繁的添加和刪除ip不會有影響。
  multicast協議
  好處：可以適應動態變化的地址。
  缺點：自動鏈接地址會過渡的消耗網絡資源

Discovery協議
    Discovery是在multicast協議的功能上定義的。功能相似與Failover功能。它將動態的發現multicast協議的broker的鏈接而且隨機的鏈接其中一個broker。

• 基本配置以下：
  discovery:(discoveryAgentURI)?transportOptions
  一、reconnectDelay：再次尋址等待時間，缺省值10
  二、initialReconnectDelay：初始化設定再次尋址等待時間，缺省值10
  三、maxReconnectDelay：最大尋址等待時間，缺省值30000
  四、useExponentialBackOff：是否嘗試BackOff重鏈接，默認是true
  五、backOffMultiplier：嘗試Backoff的次數，默認是2
  六、maxReconnectAttempts：若是異常，最大的從新鏈接個數，默認是0
  七、Group：組惟一的地址，默認是default
  示例：
  discovery:(multicast://default)?initialReconnectDelay=100
• Discovery協議的配置示例

  <broker name="foo">
  <transportConnectors>
      <transportConnector uri="tcp://localhost:0" discoveryUri="multicast://default"/>
  </transportConnectors>
  </broker>

Peer協議
    ActiveMQ提供了peer transport connector提供了更加容易的去嵌入broker網絡中。它建立一個優於vm鏈接的p2p網絡鏈接。默認格式以下：
peer://peergroup/brokerName?Key=value

• Peer協議的基本使用
      當咱們啓用了peer協議時，應用將自動的啓動內嵌broker，也將會自動的去配置其它broker來創建鏈接，前提是必需要有一個組。配置以下：
  peer://groupa/broker1?Persistent=false
      另外，生產者和消費者都各自鏈接到嵌入到本身應用的broker，而且在本地的同一個組名中相互訪問數據。

• Peer協議的基本原理
  
  在本地機器斷網的狀況下，本地的client訪問本地brokerA將依然正常。
  在斷網的狀況下發送消息到本地brokerA，而後網路鏈接正常後，全部的消息將從新發送並鏈接到brokerB。
  Fanout協議

Fanout協議是同時鏈接到多個broker，默認的格式以下：
    fanout:(fanoutURI)?key=value
示例：fanout:(static:(tcp://host1:61616,tcp://host2:61616))
表示client將試圖鏈接到兩個static列表中定義的三個URI

• Fanout協議的配置參數以下：
  一、initialReconnectDelay：從新鏈接的等待時間，默認是10
  二、maxReconnectDelay：最大從新鏈接的等待時間，默認是30000
  三、useExponentialBackOff：是否嘗試BackOff重鏈接，默認是true
  四、backOffMultiplier：嘗試Backoff的次數，默認是2
  五、maxReconnectAttempts：若是異常，最大的從新鏈接個數，默認是0
  六、fanOutQueues：是否將topic消息轉換queue消息，默認false
  七、minAckCount：Broker鏈接的最小數，默認是2
  配置示例：
  fanout:(static:(tcp://localhost:61616,tcp://remotehost:61616))?
  initialReconnectDelay=100
  注意：ActiveMQ並不推薦Consumer使用fanout協議。當Provider發送消息到多個broker中，測試Consumer可能受到重複的消息。