【Java進階面試系列之三】哥們，消息中間件在大家項目裏是如何落地的？【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

1、前情回顧

以前給你們聊了一下，面試時若是遇到消息中間件這個話題，面試官上來可能問的兩個問題：

• 大家的系統架構中爲何要引入消息中間件？
• 系統架構中引入消息中間件有什麼缺點？

關於這兩個問題的回答，能夠參見以前的兩篇文章：

• 「Java進階面試系列之一」大家系統架構中爲什麼要引入消息中間件？
• 「Java進階面試系列之二」系統架構引入消息中間件有什麼缺點

在問完這兩個問題以後，不一樣風格的面試官可能會展開不一樣的發問。

針對那種工做年限比較長的資深的同窗，可能會開始就候選人所在公司使用的消息中間件，深刻裏面的技術細節，好比讓你聊聊RocketMQ的架構原理和核心源碼？

可是另一種面試風格，會先從大家的項目和業務入手進行考察，好比像下面這樣：

• 消息中間件在大家生產項目裏具體是哪一個業務場景下落地的？
• 這個業務場景有什麼技術挑戰？
• 爲何必需要在這個業務場景裏用消息中間件技術？
• 具體使用消息中間件的時候是怎麼來用的？

好！這篇文章，我們從第二種風格來聊聊。

2、業務場景介紹

咱們會落地到某個具體業務系統的某個場景下，看看如何使用消息中間件，而後其效果是什麼。

業務場景的話，我們就用你們都很熟悉的電商業務爲例，這裏爲了便於理解，對其作了必定的抽象和簡化。

你們仍是來考慮一個下訂單的業務流程，好比你下個訂單，此時須要幹幾件事情：

1. 更新訂單狀態爲「待發貨」（耗時20ms）
2. 扣減商品庫存（耗時100ms）
3. 增長會員積分（耗時80ms）
4. 附贈優惠券（耗時50ms）
5. 倉儲調度發貨（耗時幾十秒）。

說明一下：上述環節，爲了便於你們理解，作了簡化。實際真正複雜的電商系統裏，總體環節和業務流程會比這個複雜不少倍，並且耗時也絕對不是上面那麼簡單的。

老規矩！咱們仍是經過一張手繪圖，來看看這整個的業務流程：

如上圖，這個下訂單的業務流程中：

更新訂單狀態（20ms） + 扣減商品庫存（100ms） + 增長會員積分（80ms） + 附贈優惠券（50ms） = 250ms。

也就是說，僅僅是這4個流程的話，也就200多毫秒的耗時。

200多毫秒的耗時，對用戶下單體驗來講是很是快速的，幾乎就是一瞬間就完成了，不會感到過多的停頓，也就是一會兒就能夠看到本身下單成功了。

可是，若是加上那個調度倉儲發貨呢？

那個環節須要讀取大量的數據、使用多倉庫/多貨位的調度算法、還要跟C/S架構的倉儲系統進行網絡通訊，所以咱們這裏假設這個環節可能會耗時數十秒。

一旦加上那個調度倉儲發貨的環節到這個下單流程裏，就可能致使用戶要等頁面卡頓幾十秒後纔會看到下單成功的提示，這個用戶體驗就至關的差了。

按照以前一篇文章「Java進階面試系列之一」大家系統架構中爲什麼要引入消息中間件？的說法。對於這種場景，徹底適合使用消息中間件來進行異步化調用。

也就是說，訂單服務對倉儲調度發貨，僅僅是發送一個消息到MQ裏，而後倉儲服務消費消息以後再慢慢的執行調度算法，而後分配商品發貨任務給對應的倉庫便可。

這樣的話，就能夠把耗時幾十秒的倉儲調度發貨的環節，從下單流程裏摘除出去了。進而保證下單流程就僅僅是耗時200多毫秒而已。

至於那個耗時幾十秒的倉儲調度發貨環節，咱們經過異步的方式慢慢執行便可，不會影響用戶下單的體驗。

以上過程，咱們一樣來一張圖，你們直觀的感覺一下：

3、初步落地

好！接下來咱們就假設你們在實際生產中還沒用過消息中間件，我們從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架構經驗傾囊相授

推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理坑爹呀！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算

1三、億級流量系統架構之如何設計高容錯分佈式計算系統

1四、億級流量系統架構之如何設計承載百億流量的高性能架構

1五、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

1六、億級流量系統架構之如何設計全鏈路99.99%高可用架構

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

20、大白話聊聊Java併發面試問題之談談你對AQS的理解？

2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？

2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？

2六、【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？

2七、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷