xjjdog以前寫過很多關於消息隊列的文章。今天介紹一下ActiveMQ。其他的可以參考這些鏈接。
-----
ActiveMQ是最常用、特性最豐富的消息中間件，通常用於消息異步通信、削峰解耦等多種場景，是JMS規範的實現者之一。功能豐富到什麼程度呢？支持大部分消息協議，而且支持XA。

它也是比較古老的消息隊列，雖然最近新版本改名為Artemis，也不能去掉它身上滄桑的味道。就這麼一個重量級的東西，在很多公司尾大不掉，具體架構設計讓我為你娓娓道來。或許你應該從人性上，而不是技術上，來考慮一下它的存在性。

以下是正文。

1、架構設計概要

ActiveMQ提供兩種可供實施的架構模型：“M-S”和“network bridge”；其中“M-S”是HA方案，“網絡轉發橋”用於實現“分佈式隊列”。

1.1、M-S

Master-Slave模型下，通常需要2+個ActiveMQ實例，任何時候只有一個實例為Master，向Client提供”生產”、“消費”服務，Slaves用於做backup或者等待Failover時角色接管。

M-S模型是最通用的架構模型，它提供了“高可用”特性，當Master失效後，Slaves之一提升為master繼續提供服務，且Failover之後消息仍然可以恢復。（根據底層存儲不同，有可能會有消息的丟失）。

有以下兩方面要點：

第一，M-S架構中，涉及到選舉問題，選舉的首要條件就是需要有“排它鎖”的支持。排它鎖，可以有共享文件鎖、JDBC數據庫排它鎖、JDBC鎖租約、zookeeper分佈式鎖等方式實現。這取決你的底層存儲的機制。

第二，M-S架構中，消息存儲的機制有多種，“共享文件存儲”、“JDBC”存儲、“非共享存儲”等。不同存儲機制，各有優缺點。在使用的時候一定要權衡。

1.2、網絡轉發橋（network bridge）

無論如何，一組M-S所能承載的消息量、Client併發級別總是有限的，當我們的消息規模達到單機的上限時，就應該使用基於集群的方式，將消息、Client進行分佈式和負載均衡。

ActiveMQ提供了“網絡轉發橋”模式，核心思想是：

1、集群中多個broker之間，通過“連接”互相通信，並將消息在多個Broker之間轉發和存儲，提供存儲層面的“負載均衡”。

2、根據Client的併發情況，對Client進行動態平衡，最終實現支持大規模生產者、消費者。

這和Kafka的核心思想是相似的。

2、M-S架構設計詳解

2.1、非共享存儲模式

集群中有2+個ActiveMQ實例，每個實例單獨存儲數據，Master將消息保存在本地後，並將消息以異步的方式轉發給Slaves。

Master和slaves獨立部署，各自負責自己的存儲，Master與slaves之間通過“network connector”連接，通常是Master單向與slaves建立連接。master上接收到的消息將會全量轉發給slaves。

有下面幾個要點：

1）任何時候只有Master向Clients提供服務，slaves僅作backup。古老的影子節點方式。
2）slaves上存儲的消息，有短暫的延遲。
3）master永遠是master，當master失效時，我們不能隨意進行角色切換，最佳實施方式就是重啟master，只有當master物理失效時才會考慮將slave提升為master。（這個真是弱爆了）
4）當slaves需要提升為master時，應該確保此slaves的消息是最新的。
5）如果slaves離線，那麼在重啟slaves之前，還應該將master的數據手動同步給slaves。否則slave離線期間的數據，將不會在slaves上覆現。
6）Client端不支持failover協議；即Client只會與master建立連接。

這種架構，是最原始的架構，易於實時，但是問題比較嚴重，缺乏Failover機制，消息的可靠性我們無法完全保障，因為master與slaves角色切換沒有仲裁者、或者說缺少分佈式排它鎖機制。

2.2、共享文件存儲

即採用SAN（GFS）技術，基於網絡的全局共享文件系統模式（真是一個名次製造機器），這種架構簡單易用，但是可架構、可設計的能力較弱，在Production環境下酌情采用。

SAN存儲，可以參考GFS。其中master和slaves配置保持一致，每個broker都需要有唯一的brokerName；broker實例在啟動時首先通過SAN獲取文件系統的排它鎖，獲取lock的實例將成為master，其他brokers將等待lock、並間歇性的嘗試獲取鎖，slaves不提供Clients服務；因為brokers將數據寫入GFS，所以在failover之後，

我們通常使用kahaDB作為存儲引擎，即使用日誌文件方式；kahaDB的存儲效率非常的高，TPS可以高達2W左右，是一種高效的、數據恢復能力強的存儲機制。

這種架構模式下，支持failover，當master失效後，Clients能夠通過failover協議與新的master重連，服務中斷時間很短。因為基於GFS存儲，所以數據總是保存在遠端共享存儲區域，所以不存在數據丟失的問題。

唯一的問題，就是GFS（SAN）的穩定性問題。這一點需要確定，SAN區域中的節點之間網絡通信必須穩定且高效。（自己搭建比如NFS服務，或者基於AWS EFS）。

這不過是把一個問題轉移到另外一個組件上而已。

2.3、基於JDBC共享存儲

我們可以將支持JDBC的數據庫作為共享存儲層，即master將數據寫入數據庫，本地不保存任何數據，在failover期間，slave提升為master之後，新master即可從數據庫中讀取數據，這也意味著在整個週期中，master與slaves的數據視圖是一致的（同SAN架構），所以數據的恢復能力和一致性是可以保障的，也不存在數據丟失的情況（在存儲層）。

但是JDBC存儲機制，性能實在是太低，與kahaDB這種基於日誌存儲層相比，性能相差近10倍左右。

Oh my god。不過在一些低併發，純粹解耦的場景是可以的。用在高併發互聯網就是找死（互聯網不一定意味著就是高併發的）。

如果你的業務需求，表明數據丟失是難以容忍的、且SLA水平很高很高，那麼JDBC或許是你最好的選擇。

既然JDBC數據庫為最終存儲層，那麼我們很多時候需要關注數據庫的可用性問題，比如數據庫基於M-S模式等；如果數據庫失效，將導致ActiveMQ集群不可用。

JDBC存儲面臨最大的問題就是“TPS”（吞吐能力），確實比kahaDB低數倍，如果你的業務存在高峰，“削峰”的策略可以首先將消息寫入本地文件（然後異步同步給AcitveMQ Broker）。

這個時候我總是有個疑問。直接使用數據庫就好了，您廢這麼大勁上個ActiveMQ又是何苦呢。可能是為了設計而設計吧。

3、network bridges模式架構

這種架構模式，主要是應對大規模Clients、高密度的消息增量的場景；它將以集群的模式，承載較大數據量的應用。

它有下面的要求和特點。

1）有大量Producers、Consumers客戶端接入。只所以如此，或許是因為消息通道（Topic，Queue）在水平擴張的方向上，已經沒有太大的拆分可能性。所以一股腦擠在一塊。

2）或許消息的增量，是很龐大的，特別是一些“非持久化消息”。我們寄希望於構建“分佈式隊列”架構。也就是其他系統解決不了的問題，希望消息隊列能夠緩衝一下。

3）因為集群規模較大，我們可能允許集群某些節點短暫的離線，但數據恢復機制仍然需要提供，總體而言，集群仍然提供較高的可用性。

4）集群支持Clients的負載均衡，比如有多個producers時，這些producers會被動態的在多個brokers之間平衡。否則分配不均就會造成風險。

5）支持failover，即當某個broker失效時，Clients可以與其他brokers重連；當集群中有的新的brokers加入時，集群的拓撲也可以動態的通知給Clients。這個是運維人員最喜歡的，誰也不想大半夜起床搗鼓機器。

集群有多個子Groups構成，每個Group為M-S模式、共享存儲；多個Groups之間基於“network Connector”建立連接（masterslave協議），通常為雙向連接，所有的Groups之間彼此相連，Groups之間形成“訂閱”關係，比如G2在邏輯上為G1的訂閱者（訂閱的策略是根據各個Broker上消費者的Destination列表進行分類），消息的轉發原理也是基於此。

對於Client而言，仍然支持failover，failover協議中可以包含集群中“多數派”的節點地址。

對於Topic訂閱者的消息，將會在所有Group中複製存儲；對於Queue的消息，將會在brokers之間轉發，並最終到達Consumer所在的節點。

Producers和Consumers可以與任何Group中的Master建立連接並進行消息通信，當Brokers集群拓撲變化時、Producers或Consumers的個數變化時，將會動態平衡Clients的連接位置。Brokers之間通過“advisory”機制來同步Clients的連接信息，比如新的Consumers加入，Broker將會發送advisory消息（內部的通道）通知其他brokers。

集群模式提供了較好的可用性擔保能力，在某些特性上或許需要權衡，比如Queue消息的有序性將會打破，因為同一個Queue的多個Consumer可能位於不同的Group上，如果某個Group實現，那麼保存在其上的消息只有當其恢復後才能對Clients可見。

4、性能評估

綜上所述，在Production環境中，我們能夠真正意義上採用的架構，只有三種：

1）基於JDBC的共享數據庫模式：HA架構，單一Group，Group中包含一個master和任意多個slaves；所有Brokers之間通過遠端共享數據庫存取數據。對客戶端而言支持Failover協議。

2）基於Network Bridge構建分佈式消息集群：Cluster架構，集群中有多個Group，每個Group均為M-S架構、基於共享存儲；對於Clients而言，支持負載均衡和Failover；消息從Producer出發，到達Broker節點，Broker根據“集群中Consumers分佈”，將消息轉發給Consumers所在的Broker上，實現消息的按需流動。

3）基於Network Bridge的簡化改造：與2）類似，但是每個“Group”只有一個Broker節點，此Broker基於kahaDB本地文件存儲，即相對於2）Group缺少了HA特性；當Broker節點失效時，其上的消息將不可見、直到Broker恢復正常。這種簡化版的架構模式，通過增加機器的數量、細分消息的分佈，來降低數據影響故障影響的規模，因為其基於kahaDB本地日誌存儲，所以性能很高。

4.1、共享JDBC測試結果

生產端配置。

<code>Producer端（壓力輸出機器）：數量：4臺   

    硬件配置：16Core、32G，雲主機  
    軟件配置：JDK 1.8,JVM 24G  
    併發與線程：32併發線程，連接池為128，發送文本消息，每個消息128個字符實體。消息：持久化，Queue，非事務/<code>

Broker端配置。

<code>Broker端（壓力承載）  
    數量：2臺  
    硬件配置：16Core、32G，雲主機  
    軟件配置：JDK 1.8,JVM 24G  
    架構模式：M-S模式，開啟異步轉發、關閉FlowControl，數據庫連接池為1024/<code>

存儲層配置。

<code>數據庫（存儲層）  
    數量：2臺  
    硬件配置：16Core、32G，SSD（IOPS 3000）,雲主機  
    架構模式：M-S  
    數據庫：MySQL/<code>

測試結果：
1、消息生產效率：1500 TPS
2、Broker負載情況：CPU 30%,內存使用率11%
3、MySQL負載情況：CPU 46%,IO_WAIT 25%

結論：
1、基於共享JDBC存儲架構，性能確實較低。

打算採用數據庫來實現HA的同學們，你們看到這操蛋的TPS了麼？

4.2、基於非共享文件存儲的測試結果

測試單個ActiveMQ，基於kahaDB存儲，kahaDB分為兩種數據刷盤模式：

1）逐條消息刷盤
2）每隔一秒刷盤

<code><persistenceadapter>  
    <kahadb>  /<persistenceadapter>/<code>

壓力測試環境與1）保持一致，只是ActiveMQ的機器的磁盤更換為：SSD (600 IOPS)。

測試結果：

1）逐條刷新磁盤
TPS:660
Broker IO_WAIT:19%

2）每隔一秒刷新磁盤
TPS:9800
Broker IO_WAIT:1.6% （原則上優化磁盤和IOPS等，應該還能提升）

由此可見，基於日誌文件的存儲性能比JDBC高了接近5倍，其中逐條刷盤策略，消息的可靠性是最高的，但是性能卻低於JDBC。如果基於“每隔一秒刷盤”策略，在極端情況下，可能導致最近一秒的數據丟失。

還不錯，但離著kafka這樣的MQ還遠著呢。

4.3、基於轉發橋的測試結果

基於轉發橋的架構，實施成本較高，維護成本較高，架構複雜度也相對較大。本人根據實踐經驗，不推薦使用此模式。如果你希望嘗試，也無妨，畢竟它是ActiveMQ官方推薦的“分佈式隊列實現機制”，從原理上它可以支持較大規模的消息存儲。

但是，我有更輕量級的，幹麼用你呢？

4.4、最佳實踐

所以本最佳實踐是在以上測試的基礎上得來的。

如果我們最終不得不面對“海量消息”的存儲，在按照業務進行隊列拆分之後，仍然需要面臨某個單純業務的消息量是“單個M-S架構”無法滿足的。而我們又不願意承擔Cluster模式複雜度所帶來的潛在問題，此時，可以採用比較通用的“邏輯分佈式”機制。

1）構建多個M-S組，但是每個Group之間在物理上沒有關聯，即它們之間互不通信，且不共享存儲。

2）在Producer的客戶端，增加“router”層， 即開發一個Client Wrapper，此wrapper提供了Producer常用的接口，且持有多個M-S組的ConnectionFactory，在通過底層通道發送消息之前，根據message中的某個property、或者指定的KEY，進行hash計算，進而選擇相應的連接（或者Spring的包裝類），然後發送消息。這有點類似於基於客戶端的數據庫讀寫分離的策略。

3）對於Consumers，則只需要配置多個ConnectionFactory即可。

4）經過上述實踐，將消息sharding到多個M-S組，解決了消息發送效率的問題，且邏輯集群可以進行較大規模的擴展。而且對Client是透明的。

5）如果你不想開發shard-router層面，我們仍然可以基於failover協議來實現“邏輯分佈式”的消息散列存儲，此時需要在failover協議中指明所有Groups的brokers節點列表，且randomize=true。這種用法，可以實現消息在多個Group上存儲，唯一遺憾的地方時，因為缺乏“自動負載均衡策略”，可能導致消息分佈不均。

配置如下：

<code>failover:(tcp://G1.master,tcp://G1.slave,tcp://G2.master,tcp://G2.slave)?randomize=true  
//randomize必須為true/<code>

End

是的，我寫這一切的目的，就是為了讓你放棄ActiveMQ的。雖然我對它比較熟，但我知道誰更優秀。

希望改名後的Artemis，能夠給它帶來一點青春的氣息吧。

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高併發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流

閱讀更多 小姐姐味道架構設計 的文章

關鍵字: 美好，一直在身邊 實例 通信