MQ知識點彙總

1. MQ是什麼

2. MQ能作什麼

3. 消息模式

4. 使用MQ的時候須要注意什麼

5. 經常使用MQ

6. MQ的不足

7. 何時不適用MQ

8. MQ的組成

9. MQ的關注點

 

1. MQ是什麼

    MQ 是message queue ,消息隊列，也叫消息中間件、消息總線，是一種跨進程的通訊機制，用於上下游傳遞消息。遵照JMS（java message service）規範的一種軟件。數據庫由於歷史緣由，橫向擴展是一件很是複雜的工程，全部咱們通常會盡可能把流量都擋在數據庫以前。不論是無限的橫向擴展服務器，仍是縱向阻隔到達數據庫的流量，都是這個思路。阻隔直達數據庫的流量，緩存組件和消息組件是兩大殺器。

 

2. MQ能作什麼

    1）數據驅動的任務依賴：

         例如：task2在task1執行完成後才能執行，存在依賴關係

    2）解耦：上游不關心執行結果

         例如：註冊成功後發郵件

    3）上游關注執行結果，但執行時間很長

          例如：微信支付成功的回調

    4）限流（削峯）

    5）通知

    6）數據分發

         a. 註冊後咱們可能須要作不少初始化的操做，如：調用郵件服務器發送郵件、調用促銷服務贈送優惠劵、下發用戶數據到客戶關係系統等。

            那麼這時候咱們將這些操做去監聽MQ，當用戶註冊成功事後，經過MQ通知其餘業務進行操做。確保註冊用戶的性能。

         b. 後臺發佈商品的時候，商品數據須要從數據庫中轉換成搜索引擎數據（基於elasticsearch），那麼咱們應該將商品寫入數據庫後，

            再寫入到MQ，而後經過監聽MQ來生成elasticsearch對應的數據。

         c. 用戶下單後，24小時未支付，須要取消訂單。之前咱們多是定時任務循環查詢，而後取消訂單。實際上，我更推薦相似延遲MQ的方式，

            避免了不少無效的數據庫查詢，將一個MQ設置爲24小時後才讓消費者消費掉，這樣很大程度上能減輕服務器壓力。

         d. 支付完成後，須要及時的通知子系統（進銷存系統發貨，用戶服務積分，發送短信）進行下一步操做，可是，支付回調咱們都是須要保證

             高性能的，因此，我應該直接修改數據庫狀態，存入MQ，讓MQ通知子系統作其餘非實時的業務操做。這樣能保證核心業務的高效及時。

    7）分佈式事務

    8）日誌處理：

         kafka日誌處理

 

3. 消息模式

    1）點對點模式和發佈訂閱模式：是否能夠重複消費

        a. P2P模式：

            P2P模式包含三個角色：消息隊列（Queue），發送者(Sender)，接收者(Receiver)。每一個消息都被髮送到一個特定的隊列，接收者

            從隊列中獲取消息。隊列保留着消息，直到他們被消費或超時。

        b. Pub/sub模式：

           包含三個角色：主題（Topic），發佈者（Publisher），訂閱者（Subscriber） 。多個發佈者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。

    2）推模式和拉模式：消息的更新者

         a. 推(push)模式是一種基於C/S機制、由服務器主動將信息送到客戶器的技術。

         b. 拉（pull）模式與推模式相反，是由客戶器主動發起的事務。

    

4. 使用MQ的時候須要注意什麼

    1）消息必達：

        a. 消息收到先落地

        b. 消息超時、重傳、確認保證消息必達

   2）冪等性：

        a. 上半場：MQ-client生成inner-msg-id，保證上半場冪等。這個ID全局惟一，業務無關，由MQ保證。

        b. 下半場：業務發送方帶入biz-id，業務接收方去重保證冪等。這個ID對單業務惟一，業務相關，對MQ透明。

        結論：冪等性，不只對MQ有要求，對業務上下游也有要求。

   3）高效延時消息，包含兩個重要的數據結構：

        a. 環形隊列，例如能夠建立一個包含3600個slot的環形隊列（本質是個數組）

        b. 任務集合，環上每個slot是一個Set<Task>

        環形隊列是一個實現「延時消息」的好方法，開源的MQ好像都不支持延遲消息，不妨本身實現一個簡易的「延時消息隊列」，

        能解決不少業務問題，並減小不少低效掃庫的cron任務。

   4）削峯填谷

        a. MQ-client提供拉模式，定時或者批量拉取，能夠起到削平流量，下游自我保護的做用（MQ須要作的）

        b. 要想提高總體吞吐量，須要下游優化，例如批量處理等方式（消息接收方須要作的）

 

5. 經常使用MQ

 

6. MQ的不足：

    1）系統更復雜，多了一個MQ組件

    2）消息傳遞路徑更長，延時會增長

    3）消息可靠性和重複性互爲矛盾，消息不丟不重難以同時保證

    4）上游沒法知道下游的執行結果，這一點是很致命的

 

7. 何時不適用MQ

    1）上游實時關注執行結果

 

8. MQ的組成：

    1）生產者

    2）消費者

    3）隊列

    4）路由

 

9. MQ的關注點：

    1）發佈訂閱

    2）消息優先級

    3）消息有序

    4）持久化

    5）消息過濾

    6）消息可靠性：主從，同步雙寫，異步雙寫

    7）消息低延遲（RocketMQ 使用長輪詢 Pull 方式，可保證消息很是實時，消息實時性丌低亍 Push）

    8）At least Once（是指每一個消息必須投遞一次）

    9）Exactly Only Once：發送消息階段，不容許収送重複的消息；消費消息階段，不容許消費重複的消息。

    10）Broker的Buffer滿了怎麼辦?

    11）回溯消費

    12）消息堆積

    13）分佈式事務

    14）定時消息

    15）消息重試

 

 

 

消息通道對併發的支持以及在性能上的表現；消息通道是否充分地考慮了錯誤處理；對消息安全的支持；以及關於消息持久化、災備（fail over）與集羣等方面的支持。

 

 

參見：http://www.javashuo.com/article/p-ubdrypih-en.html

         http://www.javashuo.com/article/p-aalwfjgd-dv.html

         https://blog.csdn.net/KingCat666/article/details/78660535

         消息必達