【Java進階面試系列之三】哥們，訊息中介軟體在你們專案裡是如何落地的？【石杉的架構筆記】
歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
一、前情回顧
之前給大家聊了一下，面試時如果遇到訊息中介軟體這個話題，面試官上來可能問的兩個問題：
- 你們的系統架構中為什麼要引入訊息中介軟體？
- 系統架構中引入訊息中介軟體有什麼缺點？
關於這兩個問題的回答，可以參見之前的兩篇文章：
在問完這兩個問題之後，不同風格的面試官可能會展開不同的發問。
針對那種工作年限比較長的資深的同學，可能會開始就候選人所在公司使用的訊息中介軟體，深入裡面的技術細節，比如讓你聊聊RocketMQ的架構原理和核心原始碼？
但是另外一種面試風格，會先從你們的專案和業務入手進行考察，比如像下面這樣：
- 訊息中介軟體在你們生產專案裡具體是哪個業務場景下落地的？
- 這個業務場景有什麼技術挑戰？
- 為什麼必須要在這個業務場景裡用訊息中介軟體技術？
- 具體使用訊息中介軟體的時候是怎麼來用的？
好！這篇文章，咱們從第二種風格來聊聊。
二、業務場景介紹
我們會落地到某個具體業務系統的某個場景下，看看如何使用訊息中介軟體，然後其效果是什麼。
業務場景的話，咱們就用大家都很熟悉的電商業務為例，這裡為了便於理解，對其做了一定的抽象和簡化。
大家還是來考慮一個下訂單的業務流程，比如你下個訂單，此時需要幹幾件事情：
- 更新訂單狀態為“待發貨”（耗時20ms）
- 扣減商品庫存（耗時100ms）
- 增加會員積分（耗時80ms）
- 附贈優惠券（耗時50ms）
- 倉儲排程發貨（耗時幾十秒）。
說明一下：上述環節，為了便於大家理解，做了簡化。實際真正複雜的電商系統裡，整體環節和業務流程會比這個複雜很多倍，而且耗時也絕對不是上面那麼簡單的。
老規矩！我們還是通過一張手繪圖，來看看這整個的業務流程：
如上圖，這個下訂單的業務流程中：
更新訂單狀態（20ms） + 扣減商品庫存（100ms） + 增加會員積分（80ms） + 附贈優惠券（50ms） = 250ms。
也就是說，僅僅是這4個流程的話，也就200多毫秒的耗時。
200多毫秒的耗時，對使用者下單體驗來說是非常快速的，幾乎就是一瞬間就完成了，不會感到過多的停頓，也就是一下子就可以看到自己下單成功了。
但是，如果加上那個排程倉儲發貨呢？
那個環節需要讀取大量的資料、使用多倉庫/多貨位的排程演算法、還要跟C/S架構的倉儲系統進行網路通訊，因此我們這裡假設這個環節可能會耗時數十秒。
一旦加上那個排程倉儲發貨的環節到這個下單流程裡，就可能導致使用者要等頁面卡頓幾十秒後才會看到下單成功的提示，這個使用者體驗就相當的差了。
按照之前一篇文章「Java進階面試系列之一」你們系統架構中為何要引入訊息中介軟體？的說法。對於這種場景，完全適合使用訊息中介軟體來進行非同步化呼叫。
也就是說，訂單服務對倉儲排程發貨，僅僅是傳送一個訊息到MQ裡，然後倉儲服務消費訊息之後再慢慢的執行排程演算法，然後分配商品發貨任務給對應的倉庫即可。
這樣的話，就可以把耗時幾十秒的倉儲排程發貨的環節，從下單流程裡摘除出去了。進而保證下單流程就僅僅是耗時200多毫秒而已。
至於那個耗時幾十秒的倉儲排程發貨環節，我們通過非同步的方式慢慢執行即可，不會影響使用者下單的體驗。
以上過程，我們同樣來一張圖，大家直觀的感受一下：
三、初步落地
好！接下來我們就假設大家在實際生產中還沒用過訊息中介軟體，咱們從0開始，看看如何落地？
對於已經在生產中使用過訊息中介軟體的小夥伴，不妨也看看，權當複習，溫故知新！
我們以RabbitMQ為例，假如你用的訊息中介軟體是RabbitMQ，那麼我們對這個訊息中介軟體應該如何安裝和部署呢？
很簡單，RabbitMQ的官方文件裡提供了非常詳細的安裝部署步驟，你可以在自己的膝上型電腦本地安裝，也可以在公司的伺服器上部署。
現在假設你已經參考了官方文件並安裝完成，那麼接下來在程式碼層面應該怎麼來引入RabbitMQ以及在系統裡實現收發訊息呢？
下面通過一些HelloWorld級別的程式碼和一些簡單的示例圖，給大家演示一下RabbitMQ是如何收發訊息的。
對於很多在實際生產中使用過MQ的同學，這些程式碼可能對實際生產中使用過MQ的同學，顯得太簡單了。
不過考慮到很多初學者可能連用都沒有用過MQ，甚至是才聽說訊息中介軟體不久，所以筆者認為這些demo程式碼以及手工繪圖，還是很有必要。
好！看完了程式碼，這個時候，我們可以通過一張圖來想象一下兩個服務之間的通訊。
訂單服務你可以啟動多個，不同的訂單服務都可以往一個RabbitMQ的queue裡推送訊息。
倉儲服務你也可以啟動多個，多個倉儲服務會採用round-robin的輪詢演算法，每個服務例項都可以從RabbitMQ queue裡消費到一部分的訊息。
上面的圖裡，訂單服務在MQ專業術語中叫做“生產者”，英文是“Producer”，意思就是這個服務是專門負責生產訊息投遞到MQ的。
倉儲服務在MQ專業術語中叫做“消費者”，英文是“Consumer”，意思就是這個服務專門是負責從MQ消費訊息然後處理的。
這個時候，這套非同步通訊的架構就可以跑起來了。
好了，到目前為止，雖然這個程式碼還存在不少問題，但是沒關係，大體上我們已經給一些不太熟悉MQ技術的同學，從一個比較形象易於理解簡化後的電商業務場景出發，通過HelloWorld級別的示例程式碼和手工繪圖，將MQ這個技術落地跑起來了。
更進一步，各位同學完全可以參照這個文章裡的案例，思考一下：自己負責的專案裡，有沒有類似的業務場景可以使用MQ的？
然後想辦法在自己的專案裡落地使用MQ的技術來做一下非同步化，提升核心流程的效能。
這樣未來在跳槽面試的時候，才可以做到遊刃有餘，有自己的一套東西可以說。
END
【Java進階面試系列之四】哥們，如果訊息中介軟體的消費者宕機了，會怎麼樣？【敬請期待】
如有收穫，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！
一大波微服務、分散式、高併發、高可用的原創系列文章正在路上
歡迎掃描下方二維碼，持續關注：
石杉的架構筆記（id:shishan100）
十餘年BAT架構經驗傾囊相授
推薦閱讀：2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
8、拜託，面試請不要再問我TCC分散式事務的實現原理坑爹呀！
9、【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？
11、【眼前一亮！】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上？
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼？
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能？
20、大白話聊聊Java併發面試問題之談談你對AQS的理解？
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的？（上篇）
24、網際網路公司面試官是如何360°無死角考察候選人的？（下篇）
25、Java進階面試系列之一：哥們，你們的系統架構中為什麼要引入訊息中介軟體？