聊聊mq的使用場景

mq的做用

1. 經過異步方式對系統解耦
2. 增長系統的併發處理能力

經過異步方式對系統解耦

以用戶註冊爲例，通常狀況下：

分下一下，上面過程存在的一些問題：

1. 註冊過程會調用4個服務（註冊服務、郵件服務、短信服務、積分服務），服務之間依賴性太強，任何一個服務不可用，直接影響整個註冊業務
2. 接口耗時太長，每一個服務耗時100ms，註冊流程耗時400ms
3. 對用戶來講，用戶信息入庫是主要的業務流程，其餘並非響應用戶過程當中直接關注的邏輯，能夠異步進行處理

採用mq的方式實現：

過程：

• 調用註冊服務，註冊信息入庫，耗時100ms
• 投遞註冊消息到mq
• 返回註冊成功
• 對於用戶來講耗時200ms
• 其餘3個操做（發郵件、發短信、增長積分）從消息隊列中拉取消息進行處理，對於主流程來講是異步操做

將依賴於3個服務轉換爲只依賴於mq服務，只須要保證註冊服務、mq服務高可用，便可以保證註冊服務的高可用，相比保證其餘3個服務高可用上容易了許多。

增長系統的併發處理能力

以電商中的秒殺場景爲例，採用同步處理：

• 用戶點擊秒殺
• 調用訂單服務，驗證庫存、鎖定庫存
• 跳轉到支付頁面進行支付

分析一下，存在的問題：

• 驗證庫存、鎖定庫存會訪問數據庫

• 秒殺場景，商品數量有限，請求量很是大，每一個請求來了都作以上處理，直接會把數據庫壓垮，致使數據庫沒法對外提供服務，數據庫的不可用直接致使整個業務的不可用，秒殺活動打水漂。

• 大量請求會同時到達，同時去訪問數據庫，數據庫鏈接有限，致使不少請求會處於等待狀態，致使併發性能急劇降低
• 大量用戶同時操做庫存，存在爭搶數據庫鎖的狀況，容易致使死鎖

• 秒殺中數量通常是有限，大量用戶搶購，其實最終只有不多的用戶可以搶購到

你們都有在銀行辦理業務的經驗，銀行處理業務的流程：領號、排隊、等待叫號辦理業務。

秒殺中咱們也能夠參考銀行辦理業務的流程：

• 用戶點擊描述
• 系統接受到用戶請求後，生成一個惟一的編號，而後投遞一條消息（秒殺下單）到mq
• 響應用戶：秒殺正在處理中
• 秒殺系統從mq中拉取消息進行處理，處理完成以後告知用戶，這步操做對於用戶來講是異步處理的過程

從上面能夠看出，從接受用戶請求到響應用戶請求，未訪問數據庫，只有生成編號和發送消息的操做，這部分處理速度是很是快的，不存在性能的問題，數據庫也不存在壓力的問題了，全部用戶的請求都被做爲一條消息投遞到mq進行異步處理；從而解決了秒殺中同步處理遇到的各類問題。

其餘一些使用場景

1. 系統日誌的處理
   系統手機日誌，異步發送到mq，日誌服務隊從mq中拉取消息進行各類處理，關於這個之後咱們會專門討論。
2. 經過事件驅動的一些業務，也可使用mq實現

總結

1. mq是採用異步的方式來解決系統耦合性的問題，併發處理的問題；重點是在於異步，那麼什麼狀況下使用異步呢？當調用方不強依賴於被調用方的結果的時候，能夠採用異步的方式進行處理，此時可使用mq。
2. 當調用方強依賴於被調用方的結果的時候，須要使用同步的方式，不能使用mq

mq系列整個內容，咱們將討論：

1. mq的使用場景
2. 業務系統中投遞消息的幾種方式？
3. 如何確保投遞消息必定成功？
4. 消息消費的幾種方式
5. 如何確保消息至少消費一次
6. 如何保證消息消費的冪等性