ActiveMQ架構設計與實踐,需要一萬字

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角色切換沒有仲裁者、或者說缺少分布式排它鎖機制。在Production環境中，不建議採用，如果你能容忍failover期間SLA水平降級的話，也可以作為備選。

2.2、共享文件存儲

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

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

我們通常使用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測試結果

生產端配置。

Producer端（壓力輸出機器）：數量：4臺       硬體配置：16Core、32G，雲主機       軟體配置：JDK 1.8,JVM 24G       並發與線程：32並發線程，連接池為128，發送文本消息，每個消息128個字符實體。消息：持久化，Queue，非事務 

Broker端配置。

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

存儲層配置。

資料庫（存儲層）       數量：2臺       硬體配置：16Core、32G，SSD（IOPS 3000）,雲主機       架構模式：M-S       資料庫：MySQL 

測試結果：

1、消息生產效率：1500 TPS

2、Broker負載情況：CPU 30%,內存使用率11%

3、MySQL負載情況：CPU 46%,IO_WAIT 25%

結論：

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

2、影響性能的關鍵點，就是資料庫的並發IO能力，當TPS在1800左右時，資料庫的磁碟(包括slave同步IO)已經出現較高的IO_WAIT。

3、通過升級磁碟、增加IOPS，可以有效提升TPS指標，建議同時提高CPU的個數。

打算採用資料庫來實現HA的同學們，你們看到這操蛋的TPS了麼?

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

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

1)逐條消息刷盤

2)每隔一秒刷盤

<persistenceAdapter>       <kahaDB directory="${activemq.data}/kahadb" journalDiskSyncStrategy="periodic" journalDiskSyncInterval="2000"/>  </persistenceAdapter> 

壓力測試環境與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上存儲，唯一遺憾的地方時，因為缺乏「自動負載均衡策略」，可能導致消息分布不均。

配置如下：

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

End

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

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

作者簡介：小姐姐味道 (xjjdog)，一個不允許程式設計師走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高並發世界，給你不一樣的味道。

【編輯推薦】

【責任編輯：

武曉燕

TEL：[phone]】

點讚 0