[[320409]]

 xjjdog以前寫過很多關(guān)于消息隊(duì)列的文章。今天介紹一下ActiveMQ。

ActiveMQ是最常用、特性最豐富的消息中間件，通常用于消息異步通信、削峰解耦等多種場景，是JMS規(guī)范的實(shí)現(xiàn)者之一。功能豐富到什么程度呢?支持大部分消息協(xié)議，而且支持XA。

它也是比較古老的消息隊(duì)列，雖然最近新版本改名為Artemis，也不能去掉它身上滄桑的味道。就這么一個(gè)重量級的東西，在很多公司尾大不掉，具體架構(gòu)設(shè)計(jì)讓我為你娓娓道來?；蛟S你應(yīng)該從人性上，而不是技術(shù)上，來考慮一下它的存在性。

以下是正文。

1、架構(gòu)設(shè)計(jì)概要

ActiveMQ提供兩種可供實(shí)施的架構(gòu)模型：“M-S”和“network bridge”;其中“M-S”是HA方案，“網(wǎng)絡(luò)轉(zhuǎn)發(fā)橋”用于實(shí)現(xiàn)“分布式隊(duì)列”。

1.1、M-S

Master-Slave模型下，通常需要2+個(gè)ActiveMQ實(shí)例，任何時(shí)候只有一個(gè)實(shí)例為Master，向Client提供”生產(chǎn)”、“消費(fèi)”服務(wù)，Slaves用于做backup或者等待Failover時(shí)角色接管。

M-S模型是最通用的架構(gòu)模型，它提供了“高可用”特性，當(dāng)Master失效后，Slaves之一提升為master繼續(xù)提供服務(wù)，且Failover之后消息仍然可以恢復(fù)。(根據(jù)底層存儲(chǔ)不同，有可能會(huì)有消息的丟失)。

有以下兩方面要點(diǎn)：

第一，M-S架構(gòu)中，涉及到選舉問題，選舉的首要條件就是需要有“排它鎖”的支持。排它鎖，可以有共享文件鎖、JDBC數(shù)據(jù)庫排它鎖、JDBC鎖租約、zookeeper分布式鎖等方式實(shí)現(xiàn)。這取決你的底層存儲(chǔ)的機(jī)制。

第二，M-S架構(gòu)中，消息存儲(chǔ)的機(jī)制有多種，“共享文件存儲(chǔ)”、“JDBC”存儲(chǔ)、“非共享存儲(chǔ)”等。不同存儲(chǔ)機(jī)制，各有優(yōu)缺點(diǎn)。在使用的時(shí)候一定要權(quán)衡。

1.2、網(wǎng)絡(luò)轉(zhuǎn)發(fā)橋(network bridge)

無論如何，一組M-S所能承載的消息量、Client并發(fā)級別總是有限的，當(dāng)我們的消息規(guī)模達(dá)到單機(jī)的上限時(shí)，就應(yīng)該使用基于集群的方式，將消息、Client進(jìn)行分布式和負(fù)載均衡。

ActiveMQ提供了“網(wǎng)絡(luò)轉(zhuǎn)發(fā)橋”模式，核心思想是：

1、集群中多個(gè)broker之間，通過“連接”互相通信，并將消息在多個(gè)Broker之間轉(zhuǎn)發(fā)和存儲(chǔ)，提供存儲(chǔ)層面的“負(fù)載均衡”。

2、根據(jù)Client的并發(fā)情況，對Client進(jìn)行動(dòng)態(tài)平衡，最終實(shí)現(xiàn)支持大規(guī)模生產(chǎn)者、消費(fèi)者。

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

2、M-S架構(gòu)設(shè)計(jì)詳解

2.1、非共享存儲(chǔ)模式

集群中有2+個(gè)ActiveMQ實(shí)例，每個(gè)實(shí)例單獨(dú)存儲(chǔ)數(shù)據(jù)，Master將消息保存在本地后，并將消息以異步的方式轉(zhuǎn)發(fā)給Slaves。

Master和slaves獨(dú)立部署，各自負(fù)責(zé)自己的存儲(chǔ)，Master與slaves之間通過“network connector”連接，通常是Master單向與slaves建立連接。master上接收到的消息將會(huì)全量轉(zhuǎn)發(fā)給slaves。

有下面幾個(gè)要點(diǎn)：

1)任何時(shí)候只有Master向Clients提供服務(wù)，slaves僅作backup。古老的影子節(jié)點(diǎn)方式。

2)slaves上存儲(chǔ)的消息，有短暫的延遲。

3)master永遠(yuǎn)是master，當(dāng)master失效時(shí)，我們不能隨意進(jìn)行角色切換，最佳實(shí)施方式就是重啟master，只有當(dāng)master物理失效時(shí)才會(huì)考慮將slave提升為master。(這個(gè)真是弱爆了)

4)當(dāng)slaves需要提升為master時(shí)，應(yīng)該確保此slaves的消息是最新的。

5)如果slaves離線，那么在重啟slaves之前，還應(yīng)該將master的數(shù)據(jù)手動(dòng)同步給slaves。否則slave離線期間的數(shù)據(jù)，將不會(huì)在slaves上復(fù)現(xiàn)。

6)Client端不支持failover協(xié)議;即Client只會(huì)與master建立連接。

這種架構(gòu)，是最原始的架構(gòu)，易于實(shí)時(shí)，但是問題比較嚴(yán)重，缺乏Failover機(jī)制，消息的可靠性我們無法完全保障，因?yàn)閙aster與slaves角色切換沒有仲裁者、或者說缺少分布式排它鎖機(jī)制。在Production環(huán)境中，不建議采用，如果你能容忍failover期間SLA水平降級的話，也可以作為備選。

2.2、共享文件存儲(chǔ)

即采用SAN(GFS)技術(shù)，基于網(wǎng)絡(luò)的全局共享文件系統(tǒng)模式(真是一個(gè)名次制造機(jī)器)，這種架構(gòu)簡單易用，但是可架構(gòu)、可設(shè)計(jì)的能力較弱，在Production環(huán)境下酌情采用。

SAN存儲(chǔ)，可以參考GFS。其中master和slaves配置保持一致，每個(gè)broker都需要有唯一的brokerName;broker實(shí)例在啟動(dòng)時(shí)首先通過SAN獲取文件系統(tǒng)的排它鎖，獲取lock的實(shí)例將成為master，其他brokers將等待lock、并間歇性的嘗試獲取鎖，slaves不提供Clients服務(wù);因?yàn)閎rokers將數(shù)據(jù)寫入GFS，所以在failover之后，新的master獲取的數(shù)據(jù)視圖仍然與原master保持一致，畢竟GFS是全局的共享文件系統(tǒng)。

我們通常使用kahaDB作為存儲(chǔ)引擎，即使用日志文件方式;kahaDB的存儲(chǔ)效率非常的高，TPS可以高達(dá)2W左右，是一種高效的、數(shù)據(jù)恢復(fù)能力強(qiáng)的存儲(chǔ)機(jī)制。

這種架構(gòu)模式下，支持failover，當(dāng)master失效后，Clients能夠通過failover協(xié)議與新的master重連，服務(wù)中斷時(shí)間很短。因?yàn)榛贕FS存儲(chǔ)，所以數(shù)據(jù)總是保存在遠(yuǎn)端共享存儲(chǔ)區(qū)域，所以不存在數(shù)據(jù)丟失的問題。

唯一的問題，就是GFS(SAN)的穩(wěn)定性問題。這一點(diǎn)需要確定，SAN區(qū)域中的節(jié)點(diǎn)之間網(wǎng)絡(luò)通信必須穩(wěn)定且高效。(自己搭建比如NFS服務(wù)，或者基于AWS EFS)。

這不過是把一個(gè)問題轉(zhuǎn)移到另外一個(gè)組件上而已。

2.3、基于JDBC共享存儲(chǔ)

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

但是JDBC存儲(chǔ)機(jī)制，性能實(shí)在是太低，與kahaDB這種基于日志存儲(chǔ)層相比，性能相差近10倍左右。

Oh my god。不過在一些低并發(fā)，純粹解耦的場景是可以的。用在高并發(fā)互聯(lián)網(wǎng)就是找死(互聯(lián)網(wǎng)不一定意味著就是高并發(fā)的)。

如果你的業(yè)務(wù)需求，表明數(shù)據(jù)丟失是難以容忍的、且SLA水平很高很高，那么JDBC或許是你最好的選擇。

既然JDBC數(shù)據(jù)庫為最終存儲(chǔ)層，那么我們很多時(shí)候需要關(guān)注數(shù)據(jù)庫的可用性問題，比如數(shù)據(jù)庫基于M-S模式等;如果數(shù)據(jù)庫失效，將導(dǎo)致ActiveMQ集群不可用。

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

這個(gè)時(shí)候我總是有個(gè)疑問。直接使用數(shù)據(jù)庫就好了，您廢這么大勁上個(gè)ActiveMQ又是何苦呢?？赡苁菫榱嗽O(shè)計(jì)而設(shè)計(jì)吧。

3、network bridges模式架構(gòu)

這種架構(gòu)模式，主要是應(yīng)對大規(guī)模Clients、高密度的消息增量的場景;它將以集群的模式，承載較大數(shù)據(jù)量的應(yīng)用。

它有下面的要求和特點(diǎn)。

1)有大量Producers、Consumers客戶端接入。只所以如此，或許是因?yàn)橄⑼ǖ?Topic，Queue)在水平擴(kuò)張的方向上，已經(jīng)沒有太大的拆分可能性。所以一股腦擠在一塊。

2)或許消息的增量，是很龐大的，特別是一些“非持久化消息”。我們寄希望于構(gòu)建“分布式隊(duì)列”架構(gòu)。也就是其他系統(tǒng)解決不了的問題，希望消息隊(duì)列能夠緩沖一下。

3)因?yàn)榧阂?guī)模較大，我們可能允許集群某些節(jié)點(diǎn)短暫的離線，但數(shù)據(jù)恢復(fù)機(jī)制仍然需要提供，總體而言，集群仍然提供較高的可用性。

4)集群支持Clients的負(fù)載均衡，比如有多個(gè)producers時(shí)，這些producers會(huì)被動(dòng)態(tài)的在多個(gè)brokers之間平衡。否則分配不均就會(huì)造成風(fēng)險(xiǎn)。

5)支持failover，即當(dāng)某個(gè)broker失效時(shí)，Clients可以與其他brokers重連;當(dāng)集群中有的新的brokers加入時(shí)，集群的拓?fù)湟部梢詣?dòng)態(tài)的通知給Clients。這個(gè)是運(yùn)維人員最喜歡的，誰也不想大半夜起床搗鼓機(jī)器。

集群有多個(gè)子Groups構(gòu)成，每個(gè)Group為M-S模式、共享存儲(chǔ);多個(gè)Groups之間基于“network Connector”建立連接(masterslave協(xié)議)，通常為雙向連接，所有的Groups之間彼此相連，Groups之間形成“訂閱”關(guān)系，比如G2在邏輯上為G1的訂閱者(訂閱的策略是根據(jù)各個(gè)Broker上消費(fèi)者的Destination列表進(jìn)行分類)，消息的轉(zhuǎn)發(fā)原理也是基于此。

對于Client而言，仍然支持failover，failover協(xié)議中可以包含集群中“多數(shù)派”的節(jié)點(diǎn)地址。

對于Topic訂閱者的消息，將會(huì)在所有Group中復(fù)制存儲(chǔ);對于Queue的消息，將會(huì)在brokers之間轉(zhuǎn)發(fā)，并最終到達(dá)Consumer所在的節(jié)點(diǎn)。

Producers和Consumers可以與任何Group中的Master建立連接并進(jìn)行消息通信，當(dāng)Brokers集群拓?fù)渥兓瘯r(shí)、Producers或Consumers的個(gè)數(shù)變化時(shí)，將會(huì)動(dòng)態(tài)平衡Clients的連接位置。Brokers之間通過“advisory”機(jī)制來同步Clients的連接信息，比如新的Consumers加入，Broker將會(huì)發(fā)送advisory消息(內(nèi)部的通道)通知其他brokers。

集群模式提供了較好的可用性擔(dān)保能力，在某些特性上或許需要權(quán)衡，比如Queue消息的有序性將會(huì)打破，因?yàn)橥粋€(gè)Queue的多個(gè)Consumer可能位于不同的Group上，如果某個(gè)Group實(shí)現(xiàn)，那么保存在其上的消息只有當(dāng)其恢復(fù)后才能對Clients可見。

4、性能評估

綜上所述，在Production環(huán)境中，我們能夠真正意義上采用的架構(gòu)，只有三種：

1)基于JDBC的共享數(shù)據(jù)庫模式：HA架構(gòu)，單一Group，Group中包含一個(gè)master和任意多個(gè)slaves;所有Brokers之間通過遠(yuǎn)端共享數(shù)據(jù)庫存取數(shù)據(jù)。對客戶端而言支持Failover協(xié)議。

2)基于Network Bridge構(gòu)建分布式消息集群：Cluster架構(gòu)，集群中有多個(gè)Group，每個(gè)Group均為M-S架構(gòu)、基于共享存儲(chǔ);對于Clients而言，支持負(fù)載均衡和Failover;消息從Producer出發(fā)，到達(dá)Broker節(jié)點(diǎn)，Broker根據(jù)“集群中Consumers分布”，將消息轉(zhuǎn)發(fā)給Consumers所在的Broker上，實(shí)現(xiàn)消息的按需流動(dòng)。

3)基于Network Bridge的簡化改造：與2)類似，但是每個(gè)“Group”只有一個(gè)Broker節(jié)點(diǎn)，此Broker基于kahaDB本地文件存儲(chǔ)，即相對于2)Group缺少了HA特性;當(dāng)Broker節(jié)點(diǎn)失效時(shí)，其上的消息將不可見、直到Broker恢復(fù)正常。這種簡化版的架構(gòu)模式，通過增加機(jī)器的數(shù)量、細(xì)分消息的分布，來降低數(shù)據(jù)影響故障影響的規(guī)模，因?yàn)槠浠趉ahaDB本地日志存儲(chǔ)，所以性能很高。

4.1、共享JDBC測試結(jié)果

生產(chǎn)端配置。

Producer端（壓力輸出機(jī)器）：數(shù)量：4臺(tái)   
    硬件配置：16Core、32G，云主機(jī)   
    軟件配置：JDK 1.8,JVM 24G   
    并發(fā)與線程：32并發(fā)線程，連接池為128，發(fā)送文本消息，每個(gè)消息128個(gè)字符實(shí)體。消息：持久化，Queue，非事務(wù) 

Broker端配置。

Broker端（壓力承載）   
    數(shù)量：2臺(tái)   
    硬件配置：16Core、32G，云主機(jī)   
    軟件配置：JDK 1.8,JVM 24G   
    架構(gòu)模式：M-S模式，開啟異步轉(zhuǎn)發(fā)、關(guān)閉FlowControl，數(shù)據(jù)庫連接池為1024 

存儲(chǔ)層配置。

數(shù)據(jù)庫（存儲(chǔ)層）   
    數(shù)量：2臺(tái)   
    硬件配置：16Core、32G，SSD（IOPS 3000）,云主機(jī)   
    架構(gòu)模式：M-S   
    數(shù)據(jù)庫：MySQL 

測試結(jié)果：

1、消息生產(chǎn)效率：1500 TPS

2、Broker負(fù)載情況：CPU 30%,內(nèi)存使用率11%

3、MySQL負(fù)載情況：CPU 46%,IO_WAIT 25%

結(jié)論：

1、基于共享JDBC存儲(chǔ)架構(gòu)，性能確實(shí)較低。

2、影響性能的關(guān)鍵點(diǎn)，就是數(shù)據(jù)庫的并發(fā)IO能力，當(dāng)TPS在1800左右時(shí)，數(shù)據(jù)庫的磁盤(包括slave同步IO)已經(jīng)出現(xiàn)較高的IO_WAIT。

3、通過升級磁盤、增加IOPS，可以有效提升TPS指標(biāo)，建議同時(shí)提高CPU的個(gè)數(shù)。

打算采用數(shù)據(jù)庫來實(shí)現(xiàn)HA的同學(xué)們，你們看到這操蛋的TPS了么?

4.2、基于非共享文件存儲(chǔ)的測試結(jié)果

測試單個(gè)ActiveMQ，基于kahaDB存儲(chǔ)，kahaDB分為兩種數(shù)據(jù)刷盤模式：

1)逐條消息刷盤

2)每隔一秒刷盤

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

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

測試結(jié)果：

1)逐條刷新磁盤

TPS:660

Broker IO_WAIT:19%

2)每隔一秒刷新磁盤

TPS:9800

Broker IO_WAIT:1.6% (原則上優(yōu)化磁盤和IOPS等，應(yīng)該還能提升)

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

還不錯(cuò)，但離著kafka這樣的MQ還遠(yuǎn)著呢。

4.3、基于轉(zhuǎn)發(fā)橋的測試結(jié)果

基于轉(zhuǎn)發(fā)橋的架構(gòu)，實(shí)施成本較高，維護(hù)成本較高，架構(gòu)復(fù)雜度也相對較大。本人根據(jù)實(shí)踐經(jīng)驗(yàn)，不推薦使用此模式。如果你希望嘗試，也無妨，畢竟它是ActiveMQ官方推薦的“分布式隊(duì)列實(shí)現(xiàn)機(jī)制”，從原理上它可以支持較大規(guī)模的消息存儲(chǔ)。

但是，我有更輕量級的，干么用你呢?

4.4、優(yōu)秀實(shí)踐

所以本優(yōu)秀實(shí)踐是在以上測試的基礎(chǔ)上得來的。

如果我們最終不得不面對“海量消息”的存儲(chǔ)，在按照業(yè)務(wù)進(jìn)行隊(duì)列拆分之后，仍然需要面臨某個(gè)單純業(yè)務(wù)的消息量是“單個(gè)M-S架構(gòu)”無法滿足的。而我們又不愿意承擔(dān)Cluster模式復(fù)雜度所帶來的潛在問題，此時(shí)，可以采用比較通用的“邏輯分布式”機(jī)制。

1)構(gòu)建多個(gè)M-S組，但是每個(gè)Group之間在物理上沒有關(guān)聯(lián)，即它們之間互不通信，且不共享存儲(chǔ)。

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

3)對于Consumers，則只需要配置多個(gè)ConnectionFactory即可。

4)經(jīng)過上述實(shí)踐，將消息sharding到多個(gè)M-S組，解決了消息發(fā)送效率的問題，且邏輯集群可以進(jìn)行較大規(guī)模的擴(kuò)展。而且對Client是透明的。

5)如果你不想開發(fā)shard-router層面，我們?nèi)匀豢梢曰趂ailover協(xié)議來實(shí)現(xiàn)“邏輯分布式”的消息散列存儲(chǔ)，此時(shí)需要在failover協(xié)議中指明所有Groups的brokers節(jié)點(diǎn)列表，且randomize=true。這種用法，可以實(shí)現(xiàn)消息在多個(gè)Group上存儲(chǔ)，唯一遺憾的地方時(shí)，因?yàn)槿狈?ldquo;自動(dòng)負(fù)載均衡策略”，可能導(dǎo)致消息分布不均。

配置如下：

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

End

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

希望改名后的Artemis，能夠給它帶來一點(diǎn)青春的氣息吧。

作者簡介：小姐姐味道 (xjjdog)，一個(gè)不允許程序員走彎路的公眾號(hào)。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。