[[320409]]

 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。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。