本文對應視頻：https://www.bilibili.com/video/BV1Da411Y76u/ 前面兩小節白話完之后，舉一個專業點的例子。說明一下消息隊列在實際開發中的一個典型的應用場景。 ### 用戶訂單處理 先看下面的這個模型，用戶通過瀏覽器瀏覽商品并進行下單的動作。用戶下單之后，應用程序通常會做如下的一些操作： 1. 訂單管理：為用戶生成訂單 2. 庫存管理：商品庫存減1 3. 積分管理：為用戶增加積分 **請求同步處理模型：**  如果按照上圖的操作，用戶下單之后，依次同步進行訂單、庫存、積分管理操作。這樣做的缺點是用戶等待的時間會較長，特別是在系統用戶量大、并發度高的情況下，可能會出現用戶下單之后頁面超長等待的現象。"哎呀，怎么這么慢，是不是沒成功啊，再點幾下，欸欸，電腦怎么卡死了。" **請求異步處理模型：**  為了有效地提升用戶的體驗，可以在用戶下單之后，**將訂購消息發送至消息隊列(kafka的延時可以做到毫秒級)**，之后生成訂單，返回給用戶一個訂購成功的消息。用戶直接跳轉到訂單支付頁面。大家看到這里的就涉及到同步和異步。 * 同步：推送消息和訂單管理是同步進行的，為什么？因為訂單的生成是不允許延時操作的，必須先有訂單用戶才能進行支付操作。 * 異步：庫存管理和積分管理是異步操作？因為用戶下單之后并不會關心商品庫存是不是減少了；對于自己購買商品的積分，用戶通常也不會特別關注時效性。所以采用異步處理方式。 因此通過異步操作，我們**減少了同步操作的步驟，縮短用戶瀏覽等待時間，提升了用戶體驗**。除此之外，消息隊列可以有效地進行系統功能解耦，采用異步處理模型，能夠有效的進行服務解耦。 **單體應用與服務解耦**  * 在同步處理模型下，將生成訂單、用戶加積分、減庫存操作寫在一個單體應用中。修改訂單可能影響用戶積分，修改用戶積分代碼可能影響減庫存。修改應用程序中的任何一部分代碼，都需要將應用整體打包重新部署。這比較適合小團隊、用戶量小項目的開發模型。 * 在異步的處理模型下，可以將訂單管理、積分管理、庫存管理都單獨拆分為一個服務獨立運行、獨立代碼、獨立部署，彼此之間通過消息隊列或RPC進行交互。便于小團隊知識聚合、專業度增強，代碼質量的提升，單個服務測試難度的下降。當服務耦合度下降的時候，也意味著擴展能力的增強，面對更復雜的業務需求也更有的放矢。 一般來說小團隊、用戶量較小的項目很少會將“程序解耦”作為優先的選項。如果阿里巴巴從工作第一天就想把架構做成今天的樣子，它也一定不會成為今天的阿里巴巴。應用服務的解耦一定是配合著業務量的增長，團隊規模及知識儲備的提升。應用服務的解耦有很多方式，使用消息隊列就是核心選項之一。 **數據緩沖** 當我們使用到消息隊列，一定意味著“單體應用”的方式已經無法滿足我們的用戶并發度需求，無法滿足高速增長的業務量。對于高并發的處理，通常有兩種方式來緩解 1. 集群部署，增加應用實例部署規模，比如一個應用實例處理不過來的請求，通過部署多個實例來完成，配合有效的負載均衡處理高并發需求。也就是：“一個好漢三個幫”，自己干不過來就找人來一起干。 2. 增加集群應用實例規模的方式固然有效，但是要考慮的一件事是：服務器資源是有限的，那么怎么在有限的生產力條件下，既能滿足用戶需求，又能合理的安排生產，這是“架構師”需要思考的事情。所以架構師將消息處理按照時效性分成兩類： * 對于高時效性的消息數據進行實時同步處理，如：生成訂單。 * 對于低時效性、并發度又很高的數據，先緩沖起來。消息隊列就是緩沖隊列，緩沖的目的是降低后端服務處理瓶頸，根據消息隊列后端消費服務的處理能力來拉取數據進行處理，而不是一下子把所有的數據全交給后端消費服務，把后端消費服務壓死。如：增加積分、減少庫存。 **提升數據處理性能** 既然消息隊列已經緩沖了數據，就為我們進行消息的批處理創造了條件。數據批量接收、批量處理、批量入庫的操作，一定是比我們一條一條數據的處理操作性能更高的。