日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

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

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),渦陽企業(yè)網(wǎng)站建設(shè),渦陽品牌網(wǎng)站建設(shè),網(wǎng)站定制,渦陽網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,渦陽網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

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

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

以下是正文。

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

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

1.1、M-S

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

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

有以下兩方面要點：

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

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

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

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

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

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

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

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

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

2.1、非共享存儲模式

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

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

有下面幾個要點：

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

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

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

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

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

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

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

2.2、共享文件存儲

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

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

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

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

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

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

2.3、基于JDBC共享存儲

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

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

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

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

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

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

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

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

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

它有下面的要求和特點。

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

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

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

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

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

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

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

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

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

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

4、性能評估

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

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

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

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

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

生產(chǎn)端配置。

 
 
 
 

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

Broker端配置。

 
 
 
 

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

存儲層配置。

 
 
 
 

  
  
  
  
數(shù)據(jù)庫（存儲層）   
  
  
  
  
    數(shù)量：2臺   
  
  
  
  
    硬件配置：16Core、32G，SSD（IOPS 3000）,云主機   
  
  
  
  
    架構(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存儲架構(gòu)，性能確實較低。

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

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

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

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

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

1)逐條消息刷盤

2)每隔一秒刷盤

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

測試結(jié)果：

1)逐條刷新磁盤

TPS:660

Broker IO_WAIT:19%

2)每隔一秒刷新磁盤

TPS:9800

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

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

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

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

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

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

4.4、優(yōu)秀實踐

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

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

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

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

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

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

5)如果你不想開發(fā)shard-router層面，我們?nèi)匀豢梢曰趂ailover協(xié)議來實現(xiàn)“邏輯分布式”的消息散列存儲，此時需要在failover協(xié)議中指明所有Groups的brokers節(jié)點列表，且randomize=true。這種用法，可以實現(xiàn)消息在多個Group上存儲，唯一遺憾的地方時，因為缺乏“自動負(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，能夠給它帶來一點青春的氣息吧。

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

分享名稱：ActiveMQ架構(gòu)設(shè)計與實踐，需要一萬字
新聞來源：http://www.dlmjj.cn/article/cccidji.html