1. 程式人生 > >【Java進階面試系列之三】哥們,訊息中介軟體在你們專案裡是如何落地的?【石杉的架構筆記】

【Java進階面試系列之三】哥們,訊息中介軟體在你們專案裡是如何落地的?【石杉的架構筆記】

歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100)

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

一、前情回顧

之前給大家聊了一下,面試時如果遇到訊息中介軟體這個話題,面試官上來可能問的兩個問題:

  • 你們的系統架構中為什麼要引入訊息中介軟體?
  • 系統架構中引入訊息中介軟體有什麼缺點?


關於這兩個問題的回答,可以參見之前的兩篇文章:


在問完這兩個問題之後,不同風格的面試官可能會展開不同的發問。

針對那種工作年限比較長的資深的同學,可能會開始就候選人所在公司使用的訊息中介軟體,深入裡面的技術細節,比如讓你聊聊RocketMQ的架構原理和核心原始碼?

但是另外一種面試風格,會先從你們的專案和業務入手進行考察,比如像下面這樣:

  • 訊息中介軟體在你們生產專案裡具體是哪個業務場景下落地的?
  • 這個業務場景有什麼技術挑戰?
  • 為什麼必須要在這個業務場景裡用訊息中介軟體技術?
  • 具體使用訊息中介軟體的時候是怎麼來用的?


好!這篇文章,咱們從第二種風格來聊聊。


二、業務場景介紹

我們會落地到某個具體業務系統的某個場景下,看看如何使用訊息中介軟體,然後其效果是什麼。

業務場景的話,咱們就用大家都很熟悉的電商業務為例,這裡為了便於理解,對其做了一定的抽象和簡化。

大家還是來考慮一個下訂單的業務流程,比如你下個訂單,此時需要幹幾件事情:

  1. 更新訂單狀態為“待發貨”(耗時20ms)
  2. 扣減商品庫存(耗時100ms)
  3. 增加會員積分(耗時80ms)
  4. 附贈優惠券(耗時50ms)
  5. 倉儲排程發貨(耗時幾十秒)。


說明一下:上述環節,為了便於大家理解,做了簡化。實際真正複雜的電商系統裡,整體環節和業務流程會比這個複雜很多倍,而且耗時也絕對不是上面那麼簡單的。

老規矩!我們還是通過一張手繪圖,來看看這整個的業務流程:


如上圖,這個下訂單的業務流程中:

更新訂單狀態(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架構經驗傾囊相授


推薦閱讀:

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

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

3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰

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

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

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

7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍

8、拜託,面試請不要再問我TCC分散式事務的實現原理坑爹呀!

9、【坑爹呀!】最終一致性分散式事務如何保障實際生產中99.99%高可用?

10、拜託,面試請不要再問我Redis分散式鎖的實現原理!

11、【眼前一亮!】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上?

12、億級流量系統架構之如何支撐百億級資料的儲存與計算

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

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

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

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

17、七張圖徹底講清楚ZooKeeper分散式鎖的實現原理

18、大白話聊聊Java併發面試問題之volatile到底是什麼?

19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能?

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

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

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

23、網際網路公司的面試官是如何360°無死角考察候選人的?(上篇)

24、網際網路公司面試官是如何360°無死角考察候選人的?(下篇)

25、Java進階面試系列之一:哥們,你們的系統架構中為什麼要引入訊息中介軟體?

26、【Java進階面試系列之二】:哥們,那你說說系統架構引入訊息中介軟體有什麼缺點?

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