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

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

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

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

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

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

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

主流分布式MQ

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

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

認(rèn)識(shí)JMS

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

ActiveMQ消息投遞模式

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

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

ActiveMQ 指標(biāo)

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

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

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

• Master-Slave：主從方式

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

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

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

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

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

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

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

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

架構(gòu)思考

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

下期分享RabbitMQ¹

---

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

總結(jié)

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

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