分布式消息隊列MQ 認(rèn)知

分布式消息隊列（MQ）應(yīng)用場景

1）服務(wù)解耦：現(xiàn)有耦合在一起的模塊進行重新的設(shè)計，設(shè)計成可以獨立部署的多個模塊
2）削峰填谷，把流量的高峰削下來，先把消息存到一個隊列里，后面慢慢消費，常應(yīng)用雙十11秒殺等
3）異步緩存：異步緩存將緩存操作的開銷由客戶端轉(zhuǎn)移到worker。客戶端讀數(shù)據(jù)的同時，緩存數(shù)據(jù)塊的任務(wù)被交給worker在后臺異步來處理

MQ應(yīng)用的思考點

• 生產(chǎn)端可靠性投遞：特別是金融業(yè)務(wù)，要做到生產(chǎn)端100%可靠性投遞，消息發(fā)出去和數(shù)據(jù)庫要保障原子性
  常見的解決方案有兩種
  1.消息落庫，對消息狀態(tài)進行打標(biāo)
  2.消息的延遲投遞，做二次確認(rèn)，回調(diào)檢查
• 消費端冪等：可能會出現(xiàn)重復(fù)消費問題，消費端要做冪等性驗證，不能讓消息消費多次
• 高可用：服務(wù)掛機
• 可靠性：例如，kafak副本，保證消息丟失的問題
• 低延遲：
• 堆積能力：
• 擴展性
  

如何進行技術(shù)選型？

• 各個MQ的性能、優(yōu)缺點、相應(yīng)的業(yè)務(wù)場景；
• 集群架構(gòu)模式：分布式、可擴展、高可用、可維護性
• 綜合成本問題，集群規(guī)模，人員成本
• 未來的方向、規(guī)劃、思考

主流分布式MQ

• ActiveMQ：一款經(jīng)典而又古老的MQ，其功能強大，是Apache頂級開源的一款中間件，在中小型企業(yè)以及企業(yè)級的管理應(yīng)用廣泛；
• RabbitMQ：大的需求可以滿足，橫向擴展能力不是特別好；可擴展性不是很好，高可用行和可維護性很好；
• Kafka：擴展性強，高可用性具備、可維護性稍微差點，主要關(guān)注數(shù)據(jù)的高吞吐量，還有海量數(shù)據(jù)的轉(zhuǎn)儲工作
• RocketMQ：最初由阿里巴巴開源，后捐給Apache維護，擴展性強、高可用性具備，可維護性稍微差點，支持很多功能，豐富的消息拉取，消費機制以及重復(fù)消費機制等，目前開始支持分布式事務(wù)

ActiveMQ消息中間件集群架構(gòu)與原理解析

認(rèn)識JMS

JMS（java Message Service）規(guī)范，也就是java消息服務(wù)，定義了中間件的接口規(guī)范。
JMS只是接口，并沒有給予實現(xiàn)，實現(xiàn)JMS接口的消息中間件稱為 “JMS Provider”。目前知名的開源 MOM （Message Oriented Middleware，也就是消息中間件）系統(tǒng)包括Apache的ActiveMQ、RocketMQ、Kafka，以及RabbitMQ，可以說他們都 “基本遵循” 或 “參考” JMS規(guī)范，都有自己的特點和優(yōu)勢。

ActiveMQ消息投遞模式

• 點對點：生產(chǎn)者向隊列投遞一條消息，只有一個消費者呢能監(jiān)聽到這條消息（PTP），下圖所示

• 發(fā)布訂閱：生產(chǎn)者向隊列投遞一條消息，所有監(jiān)聽到該隊列的消費者都能監(jiān)聽到這條消息（P/S）,如下圖所示
  

ActiveMQ 指標(biāo)

衡量一個MOM ，主要從三個維度，服務(wù)性能、存儲堆積能力、可擴展性。

• 服務(wù)性能：性能一般，在早起傳統(tǒng)行業(yè)比較流行，但現(xiàn)如今高并發(fā)、大數(shù)據(jù)的業(yè)務(wù)場景，力不從心！
• 數(shù)據(jù)存儲：默認(rèn)采用kahadb存儲（索引文件形式存儲），也可以使用高性能的 Google level（內(nèi)存數(shù)據(jù)存儲），或 MySQL進程消息存儲（關(guān)系型數(shù)據(jù)庫存儲）。
• 集群架構(gòu)：ActiveMQ與zookeeper進行構(gòu)建，主備集群模型，多套的主備模型直接采用network的方式構(gòu)建分布式集群。

ActiveMQ集群架構(gòu)模式

• Master-Slave：主從方式

• Master-Slave集群模型的關(guān)鍵點

上圖，綠色的為主節(jié)點，灰色為備份節(jié)點，這兩個節(jié)點都是運行的狀態(tài)的。

zookeeper的作用是為了當(dāng)綠色的主節(jié)點宕機時，進行及時切換到備份的灰色節(jié)點上去，使其進行主從角色互換，用于實現(xiàn)高可用性。

這種集群模型的缺點，就是不能做到分布式的topic、queue，當(dāng)消息量巨大時，我們的MQ集群壓力過大，沒辦法滿足分布式的需求。

• Network：網(wǎng)絡(luò)通信方式，這種方式解決了消息存儲和故障轉(zhuǎn)移、broker切換的問題，可以理解為消息會進行均衡
  

• Network集群模式的關(guān)鍵點

  需要2套或多套Master-Slave集群模型才可以搞定，部署比較麻煩，直接交叉配置，相互能夠感知彼此的存在，配置例如：

雖然解決了分布式消息隊列難題，但造成很多問題，例如資源浪費，并且也可能達不到所預(yù)期的效果

架構(gòu)思考

綜上所述，本人不推薦使用ActiveMQ,具體選型看需求需要結(jié)合每種MQ的優(yōu)缺點

下期分享RabbitMQ¹

---

關(guān)注下期分享 RabbitMQ ??

總結(jié)

以上是生活随笔為你收集整理的分布式消息队列MQ的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。