MQ使用場景

消息隊列概述

消息隊列中間件是分佈式系統中重要的組件,主要解決應用解耦,異步消息,流量削鋒等問題,實現高性能,高可用,可伸縮和最終一致性架構。目前使用較多的消息隊列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ

消息隊列應用場景

以下介紹消息隊列在實際應用中常用的使用場景。異步處理,應用解耦,流量削鋒和消息通訊四個場景。

  1. 異步處理
    場景說明:用戶註冊後,需要發註冊郵件和註冊短信。傳統的做法有兩種 1.串行的方式;2.並行方式
    a、串行方式:將註冊信息寫入數據庫成功後,發送註冊郵件,再發送註冊短信。以上三個任務全部完成後,返回給客戶端。
    在這裏插入圖片描述
    b、並行方式:將註冊信息寫入數據庫成功後,發送註冊郵件的同時,發送註冊短信。以上三個任務完成後,返回給客戶端。與串行的差別是,並行的方式可以提高處理的時間
    在這裏插入圖片描述
    假設三個業務節點每個使用50毫秒鐘,不考慮網絡等其他開銷,則串行方式的時間是150毫秒,並行的時間可能是100毫秒。
    因爲CPU在單位時間內處理的請求數是一定的,假設CPU1秒內吞吐量是100次。則串行方式1秒內CPU可處理的請求量是7次(1000/150)。並行方式處理的請求量是10次(1000/100)
    小結:如以上案例描述,傳統的方式系統的性能(併發量,吞吐量,響應時間)會有瓶頸。如何解決這個問題呢?

    引入消息隊列,將不是必須的業務邏輯,異步處理。改造後的架構如下:
    在這裏插入圖片描述
    按照以上約定,用戶的響應時間相當於是註冊信息寫入數據庫的時間,也就是50毫秒。註冊郵件,發送短信寫入消息隊列後,直接返回,因此寫入消息隊列的速度很快,基本可以忽略,因此用戶的響應時間可能是50毫秒。因此架構改變後,系統的吞吐量提高到每秒20 QPS。比串行提高了3倍,比並行提高了兩倍。

  2. 應用解耦
    場景說明:用戶下單後,訂單系統需要通知庫存系統。傳統的做法是,訂單系統調用庫存系統的接口。如下圖:
    在這裏插入圖片描述
    傳統模式的缺點:假如庫存系統無法訪問,則訂單減庫存將失敗,從而導致訂單失敗,訂單系統與庫存系統耦合如何解決以上問題呢?引入應用消息隊列後的方案,如下圖:
    在這裏插入圖片描述
    訂單系統:用戶下單後,訂單系統完成持久化處理,將消息寫入消息隊列,返回用戶訂單下單成功
    庫存系統:訂閱下單的消息,採用拉/推的方式,獲取下單信息,庫存系統根據下單信息,進行庫存操作
    假如:在下單時庫存系統不能正常使用。也不影響正常下單,因爲下單後,訂單系統寫入消息隊列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦

  3. 流量削鋒
    流量削鋒也是消息隊列中的常用場景,一般在秒殺或團搶活動中使用廣泛。
    應用場景:秒殺活動,一般會因爲流量過大,導致流量暴增,應用掛掉。爲解決這個問題,一般需要在應用前端加入消息隊列。

    a、可以控制活動的人數
    b、可以緩解短時間內高流量壓垮應用
    在這裏插入圖片描述
    用戶的請求,服務器接收後,首先寫入消息隊列。假如消息隊列長度超過最大數量,則直接拋棄用戶請求或跳轉到錯誤頁面。
    秒殺業務根據消息隊列中的請求信息,再做後續處理

  4. 日誌處理
    日誌處理是指將消息隊列用在日誌處理中,比如Kafka的應用,解決大量日誌傳輸的問題。架構簡化如下
    在這裏插入圖片描述
    日誌採集客戶端,負責日誌數據採集,定時寫受寫入Kafka隊列
    Kafka消息隊列,負責日誌數據的接收,存儲和轉發
    日誌處理應用:訂閱並消費kafka隊列中的日誌數據

  5. 消息通訊
    消息通訊是指,消息隊列一般都內置了高效的通信機制,因此也可以用在純的消息通訊。比如實現點對點消息隊列,或者聊天室等

    點對點通訊:
    在這裏插入圖片描述
    客戶端A和客戶端B使用同一隊列,進行消息通訊。

    聊天室通訊:
    在這裏插入圖片描述
    客戶端A,客戶端B,客戶端N訂閱同一主題,進行消息發佈和接收。實現類似聊天室效果。

    以上實際是消息隊列的兩種消息模式,點對點或發佈訂閱模式。模型爲示意圖,供參考。

消息中間件示例

  1. 電商系統
    在這裏插入圖片描述
    消息隊列採用高可用,可持久化的消息中間件。比如Active MQ,Rabbit MQ,Rocket Mq。
    • 應用將主幹邏輯處理完成後,寫入消息隊列。消息發送是否成功可以開啓消息的確認模式。(消息隊列返回消息接收成功狀態後,應用再返回,這樣保障消息的完整性)
    • 擴展流程(發短信,配送處理)訂閱隊列消息。採用推或拉的方式獲取消息並處理。
    • 消息將應用解耦的同時,帶來了數據一致性問題,可以採用最終一致性方式解決。比如主數據寫入數據庫,擴展應用根據消息隊列,並結合數據庫方式實現基於消息隊列的後續處理。
  2. 日誌收集系統
    在這裏插入圖片描述
    分爲Zookeeper註冊中心,日誌收集客戶端,Kafka集羣和Storm集羣(OtherApp)四部分組成。
    • Zookeeper註冊中心,提出負載均衡和地址查找服務
    • 日誌收集客戶端,用於採集應用系統的日誌,並將數據推送到kafka隊列
    • Kafka集羣:接收,路由,存儲,轉發等消息處理
    • Storm集羣:與OtherApp處於同一級別,採用拉的方式消費隊列中的數據
發佈了27 篇原創文章 · 獲贊 0 · 訪問量 672
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章