訊息佇列的應用場景

應用耦合：多應用間通過訊息佇列對同一訊息進行處理，避免呼叫介面失敗導致整個過程失敗；

非同步處理：多應用對訊息佇列中同一訊息進行處理，應用間併發處理訊息，相比序列處理，減少處理時間；

限流削峰：廣泛應用於秒殺或搶購活動中，避免流量過大導致應用系統掛掉的情況；

訊息驅動的系統：系統分為訊息佇列、訊息生產者、訊息消費者，生產者負責產生訊息，消費者(可能有多個)負責對訊息進行處理；

下面詳細介紹上述四個場景以及訊息佇列如何在上述四個場景中使用：

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

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

在這種方式下，需要最終傳送驗證簡訊後再返回給客戶端。

（2）並行處理：新註冊資訊寫入後，由發簡訊和發郵件並行處理；

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

序列：50+50+50=150ms

並行：50+50 = 100ms

若使用訊息佇列：

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

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

該方法有如下缺點：

人臉識別系統被調失敗，導致上傳失敗；

延遲高，需要人臉識別系統處理完成後，再返回給客戶端，即使使用者並不需要立即知道結果；

上傳系統與人臉識別系統之間互相呼叫，需要做耦合；

若使用訊息佇列：

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

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

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

該方法有如下優點：

請求先入訊息佇列，而不是由業務處理系統直接處理，做了一次緩衝,極大地減少了業務處理系統的壓力；

佇列長度可以做限制，事實上，秒殺時，**佇列的使用者無法秒殺到商品，這些請求可以直接被拋棄，返回活動已結束或商品已售完資訊；

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

該方法有如下優點：

避免了直接呼叫下乙個系統導致當前系統失敗；

每個子系統對於訊息的處理方式可以更為靈活，可以選擇收到訊息時就處理，可以選擇定時處理，也可以劃分時間段按不同處理速度處理；