消息中間件 — 使用場景

原文地址：消息隊列及常見消息隊列介紹

消息隊列在實際應用中包括以下四個場景：

• 應用耦合：多應用間經過消息隊列對同一消息進行處理，避免調用接口失敗致使整個過程失敗；
• 異步處理：多應用對消息隊列中同一消息進行處理，應用間併發處理消息，相比串行處理，減小處理時間；
• 限流削峯：普遍應用於秒殺或搶購活動中，避免流量過大致使應用系統掛掉的狀況；
• 消息驅動的系統：系統分爲消息隊列、消息生產者、消息消費者，生產者負責產生消息，消費者(可能有多個)負責對消息進行處理；

應用耦合

具體場景：用戶使用QQ相冊上傳一張圖片，人臉識別系統會對該圖片進行人臉識別，通常的作法是，服務器接收到圖片後，圖片上傳系統當即調用人臉識別系統，調用完成後再返回成功，以下圖所示：

該方法有以下缺點：

1. 人臉識別系統被調失敗，致使圖片上傳失敗；
2. 延遲高，須要人臉識別系統處理完成後，再返回給客戶端，即便用戶並不須要當即知道結果；
3. 圖片上傳系統與人臉識別系統之間互相調用，須要作耦合；

若使用消息隊列：

客戶端上傳圖片後，圖片上傳系統將圖片信息如uin、批次寫入消息隊列，直接返回成功；而人臉識別系統則定時從消息隊列中取數據，完成對新增圖片的識別。

此時圖片上傳系統並不須要關心人臉識別系統是否對這些圖片信息的處理、以及什麼時候對這些圖片信息進行處理。事實上，因爲用戶並不須要當即知道人臉識別結果，人臉識別系統能夠選擇不一樣的調度策略，按照閒時、忙時、正常時間，對隊列中的圖片信息進行處理。

異步處理

具體場景：用戶爲了使用某個應用，進行註冊，系統須要發送註冊郵件並驗證短信。對這兩個操做的處理方式有兩種：串行及並行。

• 串行方式：新註冊信息生成後，先發送註冊郵件，再發送驗證短信；

  

  在這種方式下，須要最終發送驗證短信後再返回給客戶端。

• 並行處理：新註冊信息寫入後，由發短信和發郵件並行處理；

  

  在這種方式下，發短信和發郵件 需處理完成後再返回給客戶端。

假設以上三個子系統處理的時間均爲50ms，且不考慮網絡延遲，則總的處理時間：

串行：50+50+50=150ms 並行：50+50 = 100ms

• 若使用消息隊列

並在寫入消息隊列後當即返回成功給客戶端，則總的響應時間依賴於寫入消息隊列的時間，而寫入消息隊列的時間自己是能夠很快的，基本能夠忽略不計，所以總的處理時間相比串行提升了2倍，相比並行提升了一倍

限流削峯

具體場景：購物網站開展秒殺活動，通常因爲瞬時訪問量過大，服務器接收過大，會致使流量暴增，相關係統沒法處理請求甚至崩潰。而加入消息隊列後，系統能夠從消息隊列中取數據，至關於消息隊列作了一次緩衝。

該方法有以下優勢：

1. 請求先入消息隊列，而不是由業務處理系統直接處理，作了一次緩衝,極大地減小了業務處理系統的壓力；
2. 隊列長度能夠作限制，事實上，秒殺時，後入隊列的用戶沒法秒殺到商品，這些請求能夠直接被拋棄，返回活動已結束或商品已售完信息；

消息驅動的系統

具體場景：用戶新上傳了一批照片， 人臉識別系統須要對這個用戶的全部照片進行聚類，聚類完成後由對帳系統從新生成用戶的人臉索引(加快查詢)。這三個子系統間由消息隊列鏈接起來，前一個階段的處理結果放入隊列中，後一個階段從隊列中獲取消息繼續處理。

該方法有以下優勢：

1. 避免了直接調用下一個系統致使當前系統失敗；
2. 每一個子系統對於消息的處理方式能夠更爲靈活，能夠選擇收到消息時就處理，能夠選擇定時處理，也能夠劃分時間段按不一樣處理速度處理；

---

若是讀完以爲有收穫的話，歡迎點贊、關注、加公衆號【牛覓技術】，查閱更多精彩歷史！！！：