activemq 連接方式

ActiveMQ的主要作用就是向客戶應用程序提供面向消息通信的架構。ActiveMQ提供了一種用於客戶端和代理之間（Client-to-Broker）以及代理與代理（Broker-to-Broker）之間連接的連接器（connectors）。ActiveMQ允許客戶端的應用程序使用多種協議連接到代理，並且代理之間可以創建複雜的連接通道。

這一章中將解釋下面的連接概念：

1. 連接URIs（connector URIs），用於表示代理的地址

2. 傳輸連接（Transport connectors），將Broker暴露給客戶端使用，負責客戶端與代理之間的連接通信。

3. 網絡連接（Network Connectors），用於創建代理網絡拓撲，主要負責代理與代理之間的連接通信。

4. 發現代理（Discovery Agent），客戶端或代理用於探測並連接網絡中的其他代理。

5. 其他常用的連接器

4.1 理解連接器URIs（Connector URIs）

在描述連接器細節和他們在ActiveMQ體系結構中的作用之前，您需要了解連接器URIs。ActiveMQ中的鏈接器URIs在是一種標準URI地址。

統一資源定位符（Uniform Resource Identifiers，URIs），被WWW（world wide web）引入標識一個網絡資源。URI規範指出：一個URI標識一個抽象的或物理的資源。

每一個URI具有如下語法格式：

例如下面的URI：

mailto:[email protected]

注意到mailto是主題，後面附帶一個電子郵件地址，用來指定服務器和服務器上的具體資源。

更爲常用的URIs是一種具有等級結構的URIs，如下所示：

例如下面的實例：

http://www.nabble.com/forum/NewTopic.jtp?forum=2356

上述的URL使用了http主題，並且包含了路徑和查詢元素（查詢元素就是附加的參數）。

由於URIs的簡單靈活，ActiveMQ使用URIs定位一個特定的brokers。例如：

tcp://localhost:61616

意思是說標識一個本地的端口號位61616的TCP連接。

ActiveMQ連接器將這種簡單等級結構的URI模式稱爲低等級的連接器（low-level connectors），併爲這些連接器實現了基本的網絡通信協議。低等級連接器URIs使用主題（scheme）標識底層使用的網絡協議，使用路徑元素定位網絡資源服務（一般爲主機名加上端口號），使用查詢元素用來確定連接器附加信息。如下圖：

如果使用符合URIs，當一個客戶端連接不可用時，ActiveMQ中的TCP傳輸連接器會使用自動重連接。複合重連接示例如下：

可以看出URI的主題使用static協議，路徑部分包含了多個低層次的URIs。每個低層次的URIs都可以有自己的參數。

注意，不要在多個低等級的URI之間添加任何空白符，這是URI規範所不允許的，這也是一種常見的ActiveMQ配置錯誤。

4.2 配置傳輸連接器。

客戶端與代理（Client-to-Broker）之間的通信連接器稱爲傳輸連接器（transport connectors）。

傳輸連接器用於接收和監聽客戶端的請求。您可以從默認的ActiveMQ的配置文檔（conf/Activemq.xml）中看到一些對傳輸連接器的配置，如下：

正如您看到的，傳輸連接器組使用<transportConnectors>元素進行定義，通過<transportConnector>來定義單個連接器。ActiveMQ中可以使用多種協議的在不同端口上進行監聽。URI定義網絡協議和可選的參數，通過URI將ActiveMQ的連接暴露給外部客戶端或者其他代理進行鏈接。上述描述的在openwire連接器中定義DiscoveryUrl屬性是可選的。

在ActiveMQ啓動時，您可以看到連接器啓動的狀況：

在客戶端可以使用下面的方法連接到ActiveMQ：

上面的例子中，使用TCP協議，與ActiveMQ中介取得連接。

需要注意的是，URI的參數字段有些僅適用於代理中介的配置，有些僅適用於客戶端連接使用，有些兩者都適用，在您使用參數時，請參考相關協議文檔。

4.2.1 使用傳輸連接器

略

4.2.2 使用網絡協議

通常的使用場景是這樣的，將ActiveMQ以一個Java應用程序單獨運行，這就意味着客戶端（消息發送者和消費者）需要使用一些網絡協議才能訪問目標代理中介。

4.2.2.1 傳輸控制協議（transmission control protocol TCP）

TCP協議是一種以包交換進行主機通信的可靠的傳輸協議。

由於客戶端應用程序和代理之間希望以一種可靠的方式進行通信，所以使用TCP協議實現JMS是合理的，並且也是ActiveMQ中使用最多的協議。

在消息進行交換之前，需要將他們串行化爲特定的傳輸格式。將消息串行化成比特序列的協議稱爲包裝協議（wire protocol）。ActiveMQ默認使用的包裝協議爲OpenWire協議。包裝的目的是使得網絡消息傳輸更有效更快速。除此之外，包裝協議還會允許消息在不同編程語言編寫的應用之間進行交換。爲了完成消息的包裝，TCP傳輸連接器使用OpenWire協議將消息串行化並通過TCP協議在網絡上進行傳輸。

正如我們前面看到的那樣，默認的TCP連接器使用61616端口。

Tcp://hostname:port?key=value&key=value

示例如下：

上例中使用了trace選項，表明所有的連接都需要記錄日誌，一般用於對brokers調試。注意當配置文檔修改後，必須重新啓動ActiveMQ，配置才能生效。

使用TCP傳輸連接器的優點：

1. 高效 – TCP連接器默認情況下使用OpenWire協議對傳輸的消息進行串行化，這在網絡傳輸中是十分高效的。

2. 高可用 – 基本上所有的平臺都支持TCP網絡協議。

3. 可靠 – 能夠確保消息在傳輸過程中不會丟失。

4.2.2.2 新I/O API 協議（New I/O API Protocol ，NIO）

NIO是在Java SE1.4規範中定義的Java標準I/O API。NIO並不是想取代傳統Java I/O API的地位，而是提供了一種可替代的用於網絡編程和訪問操作系統底層I/O操作的方法。NIO的特點在於NIO selectors和無阻塞I/O編程，使得開發者使用同一網絡資源解決更多的網絡客戶端連接，並在服務之間平衡負載。

從使用者的角度來看，NIO傳輸連接器與TCP傳輸連接器沒有什麼必然區別，NIO在底層也使用TCP協議，並且也是用OpenWire作爲消息串行化包裝協議。唯一的區別在於底層實現的不同，NIO傳輸連接器是使用NIO API實現的。NOI傳輸連接器的使用場景：

1. 您需要有大量的客戶端連接到JMS中介。

一般來說，能夠連接到中介的客戶端的數量取決於操作系統支持的線程數量的上限。由於NIO連接器的實現與TCP連接器相比啓動了更少的線程，如果使用TCP不能夠滿足您的需要時，請考慮使用NIO。

2. 您的中介需要大量的網絡傳輸。NIO連接器與TCP連接器相比，效能上會更高一些，因爲NIO佔用更少的資源。

需要注意的是，ActiveMQ的效能調節不能簡單的通過使用哪個連接器就能完成。其他很多方面會影響到ActiveMQ的性能調節，例如，正確的選擇網絡拓撲，爲brokers設置多種選項，消息發送者和消費者的操作等。

配置NIO如下：

nio://hostname:port?key=value

一個配置的例子：

<transportonnector

Name=”tcp”

Uri=”tcp://localhost:61616?trace=true”/>

<transportConnector

Name=”nio”

Uri=”nio://localhost:61618?trace=true”/>

</transportConnectors>

下面給出一個發佈者和消費者的示例，如下圖：

從圖中看出消息發佈者和消費者可以採用不同的網絡連接器。消息發佈者使用nio發佈消息，消息消費者使用tcp消費消息。

4.2.2.3 用戶數據報協議（User Datagram Protocol ,UDP）

UDP與TCP的區別：

1． TCP是一種面向流的協議，這意味着數據包的順序將得到保證。換句話說，數據報不可能出現重複和亂序接收的現象。UDP不能保證數據包的有序接收，也不能保證數據包的重複發送。

2． TCP可以保證數據報可靠的傳輸，意味着數據報在傳輸過程中不會出現丟失。這是通過在發送者和接收者之間管理一個活躍連接完成的。UDP是一種無連接的協議，不能保證數據報的完整傳輸。

TCP用於可靠的數據傳輸，而UDP用於快速的數據傳輸。

你可以使用UDP連接到ActiveMQ。語法如下：

Udp://hostname:port?key=value

TCP和UDP傳輸連接器的比較：

UDP的優勢：

1. 代理安裝在防火牆後面，防火牆不允許使用TCP，這種情況您只能使用UDP。

2. 應用是時間敏感的，您想盡量消除網絡延時。

UDP的劣勢：

1. UDP是不可靠的，您可能丟失一些消息，所以您的應用程序應當解決這種消息丟失的情況。

2. 在客戶端和JMS中介之間傳遞的消息不單單是普通消息，這裏還夾雜着控制命令，如果一些控制命令由於UDP的不可靠丟失，那麼JMS連接是危險的。所以你必須提供一層可靠的傳輸確保控制消息的正確傳輸。

配置示例如下：

<transportonnector

Name=”tcp”

Uri=”tcp://localhost:61616?trace=true”/>

<transportConnector

Name=”udp”

Uri=”udp://localhost:61618?trace=true”/>

</transportConnectors>

4.2.2.4 安全套接字層協議（secure socket layer protocol，ssl）

使用TCP傳輸普通數據是不安全的，爲了確保數據傳輸的安全性需要使用Secure Sockets Layer（SSL）協議。SSL協議在TCP協議的基礎上傳輸加密的安全數據。它使用一組密鑰（公鑰和私鑰）確保傳輸通道的安全性。ActiveMQ提供了SSL傳輸連接器，SSL傳輸連接器在客戶端和代理之間的TCP連接通道上添加了一層加密協議。語法如下：

ssl://hostname:port?key=value

由於SSL傳輸是基於TCP實現的，所有配置上也和TCP很相似。在默認的情況下SSL的端口號是61617。配置示例如下：

<transportonnector

Name=”tcp”

Uri=”tcp://localhost:61616?trace=true”/>

<transportConnector

Name=”ssl”

Uri=”ssl://localhost:61617?trace=true”/>

</transportConnectors>

需要特別注意的是SSL需要一個證書和密鑰。具體內容參考原版ActiveMQ in Action第100頁。略。

4.2.4.5 超文本傳輸協議（HTTP/HTTPS）

在一些環境下，防火牆僅允許使用一些基礎的協議訪問。這是HTTP協議出現的原因。

ActiveMQ實現了HTTP傳輸連接器，能夠提供基於xml的消息傳輸。可以使用HTTP協議繞過防火牆。

語法如下：

http://hostname:port?key=value

https://hostname:port?key=value

示例：

<transportonnector

Name=”tcp”

Uri=”tcp://localhost:61616?trace=true”/>

<transportConnector

Name=”http”

Uri=”http://localhost:8080?trace=true”/>

</transportConnectors>

略。

4.2.3 使用虛擬機協議（Virtual Machine Protocol, VM）

前面討論的都是客戶端通過網絡協議連接到中介。ActiveMQ可以內嵌到Java應用程序中，這就允許客戶端與中介之間的交互通過本地JVM完成，而不是通過網絡。爲了支持這種VM內部通信，ActiveMQ提供了VM協議。

4.2.3.1 VM協議

Java應用程序使用VM傳輸連接器加載一個內嵌的中介代理並且與之連接。使用VM表示在客戶端和內嵌的中介之間不需要網絡連接，通信是直接使用方法調用的形式。由於不使用網絡協議棧，效能會得到明顯的提高。當第一個連接使用VM協議被創建時中介被開啓。同一虛擬機的後續的VM傳輸連接都會連接到同一個中介。

使用VM協議創建的中介具有獨立ActiveMQ的所有特性，並且這個中介也可以被其他的傳輸連接配置。當所有的連接到這個VM傳輸連接代理的連接都結束後，中介代理將會自動關閉。

語法如下：

vm://brokerName?key=value

VM 的代理名字在這裏起到了至關重要的作用，用於標識一箇中介。例如，您可以通過指定特定的中介名字創建不同的內嵌代理。不同的內嵌代理名字必須不同。

VM傳輸協議配置屬性中與其他連接不同之處在於，可以通過參數來調節代理性能。以Broker.開頭的屬性用於調節中介的性能。例如下面的配置終止持久化：

Vm://broker1?marshal=false&broker.persistent=false

可替代的URI語法：

Vm:broker(transprotURI,network:networkURI)/brokerName?key=value

實例如下：

Vm:broker:(tcp://localhost:6000)?brokerName=embeddedbroker&persistent=false

上例中我們定義了一個名字爲embeddedBroker的內嵌中介，並且配置了TCP傳輸連接在端口6000進行監聽。最後取消了代理的持久化。如下圖所示：

上圖給出了客戶端可以通過TCP連接到一個內嵌的代理。

可以通過配置文件對內嵌代理進行配置，然後進行引用，如下：

Vm://localhost?brokerConfig=xbean:activemq.xml

這個例子將會從classpath使用XBean協議加載activemq.xml文件配置內嵌代理。

使用內嵌代理的一個明顯好處就是改進了客戶端和代理之間的通信。並且您的Java應用僅需要一個應用程序（一個jvm中）而不是兩個（獨立運行ActiveMQ時，ActiveMQ自身是一個Java應用程序），簡化您的程序配置過程。同時也意味着減少一個Java處理過程。

另一方面，如果很多的Java應用程序使用一個內嵌的代理，管理問題可能就會出現。這種情況應當使用單獨的集羣式代理而不是內嵌代理。

4.3 配置網絡連接器（Network Connectors）

當應用程序具有大規模和高可用性需求時，最好使用網絡代理（Network of brokers）。一個網絡代理創建一個有多個ActiveMQ實例組成的集羣系統，他們之間連接完成複雜的消息使用場景。前面討論的是由客戶端和代理之間的連接，這裏強調的是代理與代理之間的連接。默認的網絡連接通道是單向的。同時ActiveMQ也支持雙向的通道。如下圖所示：

網絡連接器的配置是通過對ActiveMQ的xml文檔進行配置完成的，如下所示：

網絡連接器有一個重要概念叫發現（Discovery）。發現就是探測遠程的代理服務的過程。客戶端經常想要發現可用代理。代理本身也想發現其他的可用代理，這樣就可以創建網絡（集羣式）代理了。

有兩種形式的方法配置和連接客戶端到網絡代理。一種方法是客戶端使用靜態的方法配置訪問特定的網絡代理。另外一種方法是代理或者客戶端可以使用發現中介（agents）動態的探測代理。

4.3.1 定義靜態的網絡代理（static Networks）

靜態網絡代理連接要求您知道您需要使用的網絡代理的URIs列表。

4.3.3.1 靜態協議（static Protocol）

靜態網絡連接器（static Network connector）用來爲多代理創建靜態的連接。這些協議使用組合URI – 即，一個URI中包含了其他的URIs。組合URI中包含了多個代理的地址（URIs）。語法如下：

Static:(uri1,uri2,uri3,…)?key=value

下面給出一個配置實例：

<networkConnector name=”local network”

Uri=”static://(tcp://remotehost1:61616,tcp://remotehost2:61616)”/>

</networkConnectors>

假設，您使用的Broker爲localhost，並且remotehost1和remotehost2這兩個Broker已經開啓。輸出信息如下：

上面的輸出表明：localhost已經成功的與其他兩個代理之間創建了轉送橋接（forwarding bridge），換句話說，發往本地代理的消息將會轉發到遠程主機1和遠程主機2。

4.3.1.2 Failover Protocol

到目前爲止，客戶端都是連接到一個指定的代理。但是如果指定代理不可用該如何處理。可以有兩種可用的方案。第一種方案是，你提供一個靜態的可用代理鏈表，使用failover transport connector。另外一種方案是，動態的去發現可用的代理。

語法：

Failover:(uri1, … , uriN)?key=value

或者：

Failover:uri1, … ,uriN)

在默認情況下會採用一種隨機算法選取一個連接器進行鏈接。如果一個出現錯誤，那麼連接器會選擇另外一個連接器進行鏈接。默認的連接採用一種重連接延遲邏輯（reconnection delay logic），意味着，一個連接失敗後將延遲10ms重新啓動，之後將以30000ms重新嘗試。重試連接將是無限此的。當然您可以使用相應的參數來配置重新連接。

4.3.2 定義動態網絡（Dynamic networks）

4.3.2.1 多播協議（Multicast Protocol）

ActiveMQ代理使用多播協議使本地的服務和代理創建網絡代理。客戶端可以使用多播協議定位本地代理並創建連接。

語法：

Muticast://ipaddress:port?key=value

實例：

<broker xmlns=http://activemq.apache.org/schema/core brokerName=”multicast”

dataDirectory=”${activema.base}/data”>

</networkConnectors>

<transportConnector name=”openwire” uri=”tcp://localhost:61616”

discoveryUri=”multicast://default”/>

</broker>

在例子中的default組用來代表特殊的IP地址。這意味着，代理將會使用239.255.2.3地址發送多播包。

需要強調的是，多播僅能在本地局域網中使用（local area Network，LAN）。這是由於使用IP 多播協議的限制。

多播協議多用於代理更替頻繁的情況下。

多播協議的缺陷之一是，你可能不希望有些代理接收一些消息，這種配置是相當複雜的。另外，多播可能會造成巨大的網絡負擔。很多網絡管理員將不允許使用多播協議。當您打算使用多播協議時，請綜合考慮利弊。

4.3.2.2 發現協議（Discovery Protocol）

發現傳輸連接器（Discovery transport connector）用於客戶端使用多播協議發現可用的ActiveMQ。他將動態的發現可用代理並且隨機選擇其中一個代理進行鏈接。

語法：

Discovery:(discoveryAgentURI)?key=value

4.2.2.3 對等協議（Peer Protocol）

對等傳輸連接器（peer transport connector）是用於嵌入式代理構建網絡代理的協議。

語法如下：

Peer://peergroup/brokerName?key=value

例如：

4.3.2.4 扇出協議（fanout Protocol）

使用扇出傳輸連接，一個客戶端可以連接多個代理。

Fanout:(fanoutURI)?key=value

例如：

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

如圖所示：

使用動態扇出：

Fanout:(multicast://default)

不提倡消費者使用扇出協議，他主要適用於生產消息發向多個代理。如果多個代理出現環路，可能造成消費者接收重複的消息。所以，扇出協議僅適用於將消息發送給多個不相連接的代理。

4.4 總結

現在您應該瞭解了ActiveMQ的URIs和不同的傳輸連接器。內嵌的代理和網絡型代理，並知道如何使用和配置他們。最後你也瞭解了重連接協議和發現代理。

當您要搭建JMS系統的拓撲結構是，知道並理解不同的連接器類型和協議間的不同是非常重要的。

activemq 連接方式

python gdal 安裝使用（Windows， python 3.6.8）

多線程之BlockingQueue中 take、offer、put、add的一些比較

EXTJS 給Tree設置字體

activemq 設置admin 頁面的帳號和密碼

深入理解 jdk 動態代理的實現

JAVA wait(), notify(),sleep詳解

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結