1.優勢，使用場景
（1）異步處理
（2）解耦
（3）抗壓
2.使用代價
（1）維護成本，掛掉怎麼辦，消息丟失怎麼辦
（2）數據一致性
3.選擇消息隊列
如何分析？
1.分析是否符合業務的基本要求，市面常見基本標準是否滿足,接下來是性能，穩定性，安全性，最後一點是否有業界參考案例。
2.缺點，不滿足什麼要求，相互對比的劣勢，要求成本
RabbitMq:
優點：簡單，易用，具備點對點，訂閱模式，消息確認等常見消息隊列特點，快速上手
缺點：erlang編寫，出現問題很難定位，二次開源麻煩；消息堆積能力差；與同款產品相比性能相對低點，每秒幾萬
參考場景：小項目，同步改異步，用來解決一部分問題，開箱即用
RocketMq:
優點：具備常見消息隊列的功能，包括事務消息；性能高，毫秒級消費，每秒十幾萬消費能力；穩定，有很多項目參考案例。
缺點：與很多框架生態集成不太容易
參考場景：實時性要求高的金融業務項目
kafka:
優點：具備基本功能，包括事務消息；性能高，表現在處理量大不是速度快；穩定，有很多項目參考案例；大數據領域生態發展好
缺點：消息延時處理稍差，
參考場景：數據埋點，日誌記錄，大數據相關處理
4.消息模型
RabbitMq：
主要思路：
生產者通過exchange 投放到隊列，然後消費者從隊列拉取消息進行消費
發佈-訂閱模式怎麼實現？ 通過exchange 投放到多個隊列，多個消費者消費
rabbitmq 各大模式也主要是在exchange上動手腳
RocketMq:
主要思路：
生產者生產消息根據nameserver 獲取broker信息，再投遞到具體的broker下的topic 的隊列裏面，消費者是一個組也可以是一臺機器，消費一個或多個topic下隊列的消息
發佈訂閱核心概念和rabbitMq 不一樣的點在於：
rocketMq 是多個消費者組訂閱同一個topic，只有一個隊列有值，每個組各自消費
rabbitMq 是多個隊列裏面都有值，每個隊列的消費者消費就是發佈訂閱
5.使用
基於不同的設計思路，使用方式也不一樣，各自功能也不一樣
RabbitMq相關模式:
1基於隊列
生產者與消費者一對一；
生產者與消費者一對多(work),只有一個能消費，不是每個都消費；
2.基於交換器exchange，發佈訂閱
(1)direct交換器，一對一key關聯一致的隊列
(2)fanout 交換器綁定的所有隊列
(3)topic key通配符模糊匹配
可以看出RabbitMq的設計以及思路還是相對簡單的
RocketMq 相關模式