訊息中介軟體 — 使用場景

牛覓發表於2018-05-21

原文地址：訊息佇列及常見訊息佇列介紹

訊息佇列在實際應用中包括如下四個場景：

應用耦合：多應用間通過訊息佇列對同一訊息進行處理，避免呼叫介面失敗導致整個過程失敗；
非同步處理：多應用對訊息佇列中同一訊息進行處理，應用間併發處理訊息，相比序列處理，減少處理時間；
限流削峰：廣泛應用於秒殺或搶購活動中，避免流量過大導致應用系統掛掉的情況；
訊息驅動的系統：系統分為訊息佇列、訊息生產者、訊息消費者，生產者負責產生訊息，消費者(可能有多個)負責對訊息進行處理；

應用耦合

具體場景：使用者使用QQ相簿上傳一張圖片，人臉識別系統會對該圖片進行人臉識別，一般的做法是，伺服器接收到圖片後，圖片上傳系統立即呼叫人臉識別系統，呼叫完成後再返回成功，如下圖所示：

該方法有如下缺點：

人臉識別系統被調失敗，導致圖片上傳失敗；
延遲高，需要人臉識別系統處理完成後，再返回給客戶端，即使使用者並不需要立即知道結果；
圖片上傳系統與人臉識別系統之間互相呼叫，需要做耦合；

若使用訊息佇列：

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

此時圖片上傳系統並不需要關心人臉識別系統是否對這些圖片資訊的處理、以及何時對這些圖片資訊進行處理。事實上，由於使用者並不需要立即知道人臉識別結果，人臉識別系統可以選擇不同的排程策略，按照閒時、忙時、正常時間，對佇列中的圖片資訊進行處理。

非同步處理

具體場景：使用者為了使用某個應用，進行註冊，系統需要傳送註冊郵件並驗證簡訊。對這兩個操作的處理方式有兩種：序列及並行。

序列方式：新註冊資訊生成後，先傳送註冊郵件，再傳送驗證簡訊；

在這種方式下，需要最終傳送驗證簡訊後再返回給客戶端。
並行處理：新註冊資訊寫入後，由發簡訊和發郵件並行處理；

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

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

序列：50+50+50=150ms 並行：50+50 = 100ms

若使用訊息佇列

並在寫入訊息佇列後立即返回成功給客戶端，則總的響應時間依賴於寫入訊息佇列的時間，而寫入訊息佇列的時間本身是可以很快的，基本可以忽略不計，因此總的處理時間相比序列提高了2倍，相比並行提高了一倍

限流削峰

具體場景：購物網站開展秒殺活動，一般由於瞬時訪問量過大，伺服器接收過大，會導致流量暴增，相關係統無法處理請求甚至崩潰。而加入訊息佇列後，系統可以從訊息佇列中取資料，相當於訊息佇列做了一次緩衝。

該方法有如下優點：

請求先入訊息佇列，而不是由業務處理系統直接處理，做了一次緩衝,極大地減少了業務處理系統的壓力；
佇列長度可以做限制，事實上，秒殺時，後入佇列的使用者無法秒殺到商品，這些請求可以直接被拋棄，返回活動已結束或商品已售完資訊；

訊息驅動的系統

具體場景：使用者新上傳了一批照片，人臉識別系統需要對這個使用者的所有照片進行聚類，聚類完成後由對賬系統重新生成使用者的人臉索引(加快查詢)。這三個子系統間由訊息佇列連線起來，前一個階段的處理結果放入佇列中，後一個階段從佇列中獲取訊息繼續處理。