MQ_常見問題

應用場景

• 異步處理：
  
  • 應用解耦：
    
  • 流量削峯：
    

選型

• 吞吐量：ActiveMQ和RabbitMQ都是萬級，RocketMQ和Kafka是十萬級
• 時效性：Rabbit是微秒級，其他是毫秒級
• 可用性：ActiveMQ和RabbitMQ是主從架構，RocketMQ和Kafka是分佈式架構
• 可靠性：ActiveMQ有較低概率丟失數據
• 功能支持：ActiveMQ功能完備，RabbitMQ基於erlang開發，併發能力強，延時低，RocketMQ分佈式，擴展性好，Kafka功能簡單，主要用於大數據領域

高可用

RabbitMQ

鏡像集羣模式

• 通過管理控制檯新增鏡像集羣模式策略，可以指定數據同步到所有節點，再次創建queue時，自動將數據同步到其他節點
• 數據同步到所有節點需要性能開銷
• 擴展性差

Kafka

afka 一個最基本的架構認識：由多個 broker 組成，每個 broker 是一個節點；你創建一個 topic，這個 topic 可以劃分爲多個 partition，每個 partition 可以存在於不同的 broker 上，每個 partition 就放一部分數據。

這就是天然的分佈式消息隊列，就是說一個 topic 的數據，是分散放在多個機器上的，每個機器就放一部分數據。

重複消費

消息隊列一般會被多個下游業務監聽，如果其中某個下游業務發生異常，會觸發消息隊列的重試機制，消息隊列會重新發送消息，這樣正常執行的業務就面臨重複消費的問題。

接口冪等

在編程中一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。

冪等函數，或冪等方法，是指可以使用相同參數重複執行，並能獲得相同結果的函數。這些函數不會影響系統狀態，也不用擔心重複執行會對系統造成改變。

強校驗

業務每次收到消息，首先去相關的業務流水錶進行校驗是否已經存在處理過，如果沒有則繼續執行業務，適用於重要業務場景

弱校驗

業務處理消息，將處理結果也就是唯一流水號和相關信息存儲在Redis中，業務收到消息，首先去Redis中校驗，如果沒有則繼續執行業務，適用於不重要業務場景

消息丟失

RabbitMQ

生產者在消息傳入過程中數據丟失

• 開啓事務，同步阻塞，不推薦
• 開啓confirm模式。生產者向MQ寫入消息時會返回一個ack，如果RabbitMQ沒有處理這條消息會返回一個nack。異步，推薦

RabbitMQ消息丟失

• 設置持久化
  • 創建隊列時將其設置爲持久化
  • 發送消息時將deliveryMode 設置爲 2

消費者消息丟失

關閉RabbitMQ的自動ack，在程序中處理完成後手動ack

順序消費

問題

解決

創建多個隊列，每個隊列對應一個消費者，消費者內部再用內存隊列做排隊。

消息堆積

緊急擴容：

• 消費側出了問題，先停掉消費側，讓其修復
• 新建臨時隊列，十倍於原先的隊列數量
• 寫一個臨時的分發消費程序，將堆積的消息輪詢分發到臨時創建的隊列中
• 臨時徵用十倍於原來的機器部署消費側程序，加速消費堆積消息
• 快速消費完成後恢復原本部署的架構

過期失效

批量重導，先丟棄數據，後期手動查出來，補入隊列中

參考

https://doocs.github.io/advanced-java/#/./docs/high-concurrency/mq-interview
https://github.com/AobingJava/JavaFamily/blob/master/docs/mq/%E9%87%8D%E5%A4%8D%E6%B6%88%E8%B4%B9%E3%80%81%E9%A1%BA%E5%BA%8F%E6%B6%88%E8%B4%B9%E3%80%81%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1.md