一、簡介

MQ全稱為Message Queue-消息隊列，是一種應(yīng)用程序?qū)?yīng)用程序的消息通信，一端只管往隊列不斷發(fā)布信息，另一端只管往隊列中讀取消息，發(fā)布者不需要關(guān)心讀取消息的誰，讀取消息者不需要關(guān)心發(fā)布消息的是誰，各干各的互不干擾。

市場上現(xiàn)在常用的消息隊列有：RabbitMQ、RocketMQ、Kafka，ActiveMQ

二、MQ的優(yōu)勢

(1) 解耦

使用消息MQ后，只需要保證消息格式不變，不需要關(guān)心發(fā)布者及消費者之間的關(guān)系，這兩者不需要彼此聯(lián)系

(2) 異步

在一些不需要即時(同步)的返回結(jié)果操作，通過消息隊列來實現(xiàn)異步。

(3) 削峰

在大量請求時(秒殺場景)，使用消息隊列做緩沖處理，削弱峰值流量，防止系統(tǒng)在短時間內(nèi)被峰值流量沖垮。

場景：在大量流量涌入高峰，如數(shù)據(jù)庫只能抗住2000的并發(fā)流量，可以使用MQ控制2000到數(shù)據(jù)庫中

(4) 日志處理

日志存儲在消息隊列中，用來處理日志，比如kafka。

三、MQ的劣勢

系統(tǒng)的可用性降低

在還未引進MQ之前，系統(tǒng)只需要關(guān)系生產(chǎn)端與消費端的接口一致性就可以了，現(xiàn)在引進后，系統(tǒng)需要關(guān)注生產(chǎn)端、MQ與消費端三者的穩(wěn)定性，這增加系統(tǒng)的負(fù)擔(dān)，系統(tǒng)運維成本增加。

系統(tǒng)的復(fù)雜性提高

引入了MQ，需要考慮的問題就增加了，如何保障消息的一致性，消費不被重復(fù)消費等問題，

一致性問題

A系統(tǒng)發(fā)送完消息直接返回成功，但是BCD系統(tǒng)之中若有系統(tǒng)寫庫失敗，則會產(chǎn)生數(shù)據(jù)不一致的問題。

四、常見問題

(1) 怎么保證消息沒有重復(fù)消費？使用消息隊列如何保證冪等性

冪等性：就是用戶對于同一操作發(fā)起的一次請求或者多次請求的結(jié)果是一致的，不會因為多次點擊而產(chǎn)生了副作用

問題出現(xiàn)原因

我們先來了解一下產(chǎn)生消息重復(fù)消費的原因，對于MQ的使用，有三個角色：生產(chǎn)者、MQ、消費者，那么消息的重復(fù)這三者會出現(xiàn)：

生產(chǎn)者：生產(chǎn)者可能會推送重復(fù)的數(shù)據(jù)到MQ中，有可能controller接口重復(fù)提交了兩次，也可能是重試機制導(dǎo)致的
MQ：假設(shè)網(wǎng)絡(luò)出現(xiàn)了波動，消費者消費完一條消息后，發(fā)送ack時，MQ還沒來得及接受，突然掛了，導(dǎo)致MQ以為消費者還未消費該條消息，MQ回復(fù)后會再次推送了這條消息，導(dǎo)致出現(xiàn)重復(fù)消費。
消費者：消費者接收到消息后，正準(zhǔn)備發(fā)送ack到MQ，突然消費者掛了，還沒得及發(fā)送ack，這時MQ以為消費者還沒消費該消息，消費者重啟后，MQ再次推送該條消息。

解決方案

在正常情況下，生產(chǎn)者是客戶，我們很難避免出現(xiàn)用戶重復(fù)點擊的情況，而MQ是允許存在多條一樣的消息，但消費者是不允許出現(xiàn)消費兩條一樣的數(shù)據(jù)，所以冪等性一般是在消費端實現(xiàn)的：

狀態(tài)判斷：消費者把消費消息記錄到redis中，再次消費時先到redis判斷是否存在該數(shù)據(jù)，存在則表示消費過，直接丟棄
業(yè)務(wù)判斷：消費完數(shù)據(jù)后，都是需要插入到數(shù)據(jù)庫中，使用數(shù)據(jù)庫的唯一約束防止重復(fù)消費。插入數(shù)據(jù)庫前先查詢是否存在該數(shù)據(jù)，存在則直接丟棄消息，這種方式是比較簡單粗暴地解決問題

(2) 消息丟失的情況

(3) 消息的傳輸順序性

解決思路

在生產(chǎn)端發(fā)布消息時，每次法發(fā)布消息都把上一條消息的ID記錄到消息體中，消費者接收到消息時，做如下操作

先根據(jù)上一條Id去檢查是否存在上一條消息還沒被消費，如果不存在(消費后去掉id)，則正常進行，如果正常操作
如果存在，則根據(jù)id到數(shù)據(jù)庫檢查是否被消費，如果被消費，則正常操作
如果還沒被消費，則休眠一定時間(比如30ms)，再重新檢查，如被消費，則正常操作
如果還沒被消費，則拋出異常

(4) 怎么解決百萬消息積壓問題

根據(jù)消息重要程度，可以分為兩種情況處理

如果消息可以被丟棄，那么直接丟棄就好了
一般情況下，消息是不可以被丟棄的，那么這樣需要考慮策略了，我們可以把原來的消費端重新當(dāng)做生產(chǎn)端，重新部署一天MQ，再后面出現(xiàn)增加消費端，這樣形成另一條生產(chǎn)-消息-消費的線路

作者：MicroStone123
來源：www.jianshu.com/p/4b46be5d0ab6
版權(quán)申明：內(nèi)容來源網(wǎng)絡(luò)，僅供分享學(xué)習(xí)，版權(quán)歸原創(chuàng)者所有。除非無法確認(rèn)，我們都會標(biāo)明作者及出處，如有侵權(quán)煩請告知，我們會立即刪除并表示歉意。謝謝!

END

推薦閱讀

一鍵生成Springboot & Vue項目！【畢設(shè)神器】

Java可視化編程工具系列（一）

Java可視化編程工具系列（二）

順便給大家推薦一個GitHub項目，這個 GitHub 整理了上千本常用技術(shù)PDF，絕大部分核心的技術(shù)書籍都可以在這里找到，

GitHub地址：https://github.com/javadevbooks/books

電子書已經(jīng)更新好了，你們需要的可以自行下載了，記得點一個star，持續(xù)更新中..

一文幫你了解MQ

(1) 解耦

(2) 異步

(3) 削峰

(4) 日志處理

(1) 怎么保證消息沒有重復(fù)消費？使用消息隊列如何保證冪等性

(2) 消息丟失的情況

(3) 消息的傳輸順序性

(4) 怎么解決百萬消息積壓問題

END

推薦閱讀

一鍵生成Springboot & Vue項目！【畢設(shè)神器】

Java可視化編程工具系列（一）

Java可視化編程工具系列（二）

一文幫你了解MQ

(1) 解耦

(2) 異步

(3) 削峰

(4) 日志處理

(1) 怎么保證消息沒有重復(fù)消費？使用消息隊列如何保證冪等性

(2) 消息丟失的情況

(3) 消息的傳輸順序性

(4) 怎么解決百萬消息積壓問題

END推薦閱讀

一鍵生成Springboot & Vue項目！【畢設(shè)神器】

Java可視化編程工具系列（一）

Java可視化編程工具系列（二）

END

推薦閱讀

一鍵生成Springboot & Vue項目！【畢設(shè)神器】