一、簡介 MQ全稱為Message Queue-消息隊列，是一種應用程序對應用程序的消息通信，一端隻管往隊列不斷發布信息，另一端隻管往隊列中讀取消息，發布者不需要關心讀取消息的誰，讀取消息者不需要關心發布消息的是誰，各幹各的互不幹擾。

　　市場上現在常用的消息隊列有：RabbitMQ、RocketMQ、kafka，ActiveMQ

　　二、MQ的優勢(1) 解耦 使用消息MQ後，隻需要保證消息格式不變，不需要關心發布者及消費者之間的關系，這兩者不需要彼此聯系

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

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

　　場景：在大量流量湧入高峰，如數據庫隻能抗住2000的并發流量，可以使用MQ控制2000到數據庫中

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

　　三、MQ的劣勢系統的可用性降低 在還未引進MQ之前，系統隻需要關系生産端與消費端的接口一緻性就可以了，現在引進後，系統需要關注生産端、MQ與消費端三者的穩定性，這增加系統的負擔，系統運維成本增加。

　　系統的複雜性提高 引入了MQ，需要考慮的問題就增加了，如何保障消息的一緻性，消費不被重複消費等問題，

　　一緻性問題 A系統發送完消息直接返回成功，但是BCD系統之中若有系統寫庫失敗，則會産生數據不一緻的問題。

　　四、常見問題(1) 怎麼保證消息沒有重複消費？使用消息隊列如何保證幂等性 幂等性：就是用戶對于同一操作發起的一次請求或者多次請求的結果是一緻的，不會因為多次點擊而産生了副作用

　　問題出現原因

　　我們先來了解一下産生消息重複消費的原因，對于MQ的使用，有三個角色：生産者、MQ、消費者，那麼消息的重複這三者會出現：

　　生産者：生産者可能會推送重複的數據到MQ中，有可能controller接口重複提交了兩次，也可能是重試機制導緻的MQ：假設網絡出現了波動，消費者消費完一條消息後，發送ack時，MQ還沒來得及接受，突然挂了，導緻MQ以為消費者還未消費該條消息，MQ回複後會再次推送了這條消息，導緻出現重複消費。消費者：消費者接收到消息後，正準備發送ack到MQ，突然消費者挂了，還沒得及發送ack，這時MQ以為消費者還沒消費該消息，消費者重啟後，MQ再次推送該條消息。 解決方案

　　在正常情況下，生産者是客戶，我們很難避免出現用戶重複點擊的情況，而MQ是允許存在多條一樣的消息，但消費者是不允許出現消費兩條一樣的數據，所以幂等性一般是在消費端實現的：

　　狀态判斷：消費者把消費消息記錄到redis中，再次消費時先到redis判斷是否存在該數據，存在則表示消費過，直接丢棄業務判斷：消費完數據後，都是需要插入到數據庫中，使用數據庫的唯一約束防止重複消費。插入數據庫前先查詢是否存在該數據，存在則直接丢棄消息，這種方式是比較簡單粗暴地解決問題(2) 消息丢失的情況

　　(3) 消息的傳輸順序性 解決思路

　　在生産端發布消息時，每次法發布消息都把上一條消息的ID記錄到消息體中，消費者接收到消息時，做如下操作

　　先根據上一條Id去檢查是否存在上一條消息還沒被消費，如果不存在(消費後去掉id)，則正常進行，如果正常操作如果存在，則根據id到數據庫檢查是否被消費，如果被消費，則正常操作如果還沒被消費，則休眠一定時間(比如30ms)，再重新檢查，如被消費，則正常操作如果還沒被消費，則抛出異常(4) 怎麼解決百萬消息積壓問題 根據消息重要程度，可以分為兩種情況處理

　　如果消息可以被丢棄，那麼直接丢棄就好了一般情況下，消息是不可以被丢棄的，那麼這樣需要考慮策略了，我們可以把原來的消費端重新當做生産端，重新部署一天MQ，再後面出現增加消費端，這樣形成另一條生産-消息-消費的線路

　　,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!