一、前情回顧

針對(duì)那種工作年限比較長的資深的同學(xué)，可能會(huì)開始就候選人所在公司使用的消息中間件，深入里面的技術(shù)細(xì)節(jié)，比如讓你聊聊RocketMQ的架構(gòu)原理和核心源碼。

但是另外一種面試風(fēng)格，會(huì)先從你們的項(xiàng)目和業(yè)務(wù)入手進(jìn)行考察，比如像下面這樣：

• 消息中間件在你們生產(chǎn)項(xiàng)目里具體是哪個(gè)業(yè)務(wù)場(chǎng)景下落地的？
• 這個(gè)業(yè)務(wù)場(chǎng)景有什么技術(shù)挑戰(zhàn)？
• 為什么必須要在這個(gè)業(yè)務(wù)場(chǎng)景里用消息中間件技術(shù)？
• 具體使用消息中間件的時(shí)候是怎么來用的？

好！這篇文章，咱們從第二種風(fēng)格來聊聊。

二、業(yè)務(wù)場(chǎng)景介紹

我們會(huì)落地到某個(gè)具體業(yè)務(wù)系統(tǒng)的某個(gè)場(chǎng)景下，看看如何使用消息中間件，然后其效果是什么。

業(yè)務(wù)場(chǎng)景的話，咱們就用大家都很熟悉的電商業(yè)務(wù)為例，這里為了便于理解，對(duì)其做了一定的抽象和簡化。

大家還是來考慮一個(gè)下訂單的業(yè)務(wù)流程，比如你下個(gè)訂單，此時(shí)需要干幾件事情：

• 更新訂單狀態(tài)為“待發(fā)貨”（耗時(shí)20ms）
• 扣減商品庫存（耗時(shí)100ms）
• 增加會(huì)員積分（耗時(shí)80ms）
• 附贈(zèng)優(yōu)惠券（耗時(shí)50ms）
• 倉儲(chǔ)調(diào)度發(fā)貨（耗時(shí)幾十秒）。

說明一下：上述環(huán)節(jié)，為了便于大家理解，做了簡化。實(shí)際真正復(fù)雜的電商系統(tǒng)里，整體環(huán)節(jié)和業(yè)務(wù)流程會(huì)比這個(gè)復(fù)雜很多倍，而且耗時(shí)也絕對(duì)不是上面那么簡單的。

老規(guī)矩！我們還是通過一張手繪圖，來看看這整個(gè)的業(yè)務(wù)流程：

如上圖，這個(gè)下訂單的業(yè)務(wù)流程中：

更新訂單狀態(tài)（20ms） + 扣減商品庫存（100ms） + 增加會(huì)員積分（80ms） + 附贈(zèng)優(yōu)惠券（50ms） = 250ms。

也就是說，僅僅是這4個(gè)流程的話，也就200多毫秒的耗時(shí)。

200多毫秒的耗時(shí)，對(duì)用戶下單體驗(yàn)來說是非?？焖俚?，幾乎就是一瞬間就完成了，不會(huì)感到過多的停頓，也就是一下子就可以看到自己下單成功了。

但是，如果加上那個(gè)調(diào)度倉儲(chǔ)發(fā)貨呢？

那個(gè)環(huán)節(jié)需要讀取大量的數(shù)據(jù)、使用多倉庫/多貨位的調(diào)度算法、還要跟C/S架構(gòu)的倉儲(chǔ)系統(tǒng)進(jìn)行網(wǎng)絡(luò)通信，因此我們這里假設(shè)這個(gè)環(huán)節(jié)可能會(huì)耗時(shí)數(shù)十秒。

一旦加上那個(gè)調(diào)度倉儲(chǔ)發(fā)貨的環(huán)節(jié)到這個(gè)下單流程里，就可能導(dǎo)致用戶要等頁面卡頓幾十秒后才會(huì)看到下單成功的提示，這個(gè)用戶體驗(yàn)就相當(dāng)?shù)牟盍恕?/p>

按照之前一篇文章《為什么要使用MQ消息中間件?這幾個(gè)問題必須拿下!》的說法。對(duì)于這種場(chǎng)景，完全適合使用消息中間件來進(jìn)行異步化調(diào)用。

也就是說，訂單服務(wù)對(duì)倉儲(chǔ)調(diào)度發(fā)貨，僅僅是發(fā)送一個(gè)消息到MQ里，然后倉儲(chǔ)服務(wù)消費(fèi)消息之后再慢慢的執(zhí)行調(diào)度算法，然后分配商品發(fā)貨任務(wù)給對(duì)應(yīng)的倉庫即可。

這樣的話，就可以把耗時(shí)幾十秒的倉儲(chǔ)調(diào)度發(fā)貨的環(huán)節(jié)，從下單流程里摘除出去了。進(jìn)而保證下單流程就僅僅是耗時(shí)200多毫秒而已。

至于那個(gè)耗時(shí)幾十秒的倉儲(chǔ)調(diào)度發(fā)貨環(huán)節(jié)，我們通過異步的方式慢慢執(zhí)行即可，不會(huì)影響用戶下單的體驗(yàn)。

以上過程，我們同樣來一張圖，大家直觀地感受一下：

三、初步落地

好！接下來我們就假設(shè)大家在實(shí)際生產(chǎn)中還沒用過消息中間件，咱們從0開始，看看如何落地？

對(duì)于已經(jīng)在生產(chǎn)中使用過消息中間件的小伙伴，不妨也看看，權(quán)當(dāng)復(fù)習(xí)，溫故知新！

我們以RabbitMQ為例，假如你用的消息中間件是RabbitMQ，那么我們對(duì)這個(gè)消息中間件應(yīng)該如何安裝和部署呢？

很簡單，RabbitMQ的官方文檔里提供了非常詳細(xì)的安裝部署步驟，你可以在自己的筆記本電腦本地安裝，也可以在公司的服務(wù)器上部署。

現(xiàn)在假設(shè)你已經(jīng)參考了官方文檔并安裝完成，那么接下來在代碼層面應(yīng)該怎么來引入RabbitMQ以及在系統(tǒng)里實(shí)現(xiàn)收發(fā)消息呢？

下面通過一些HelloWorld級(jí)別的代碼和一些簡單的示例圖，給大家演示一下RabbitMQ是如何收發(fā)消息的。

對(duì)于很多在實(shí)際生產(chǎn)中使用過MQ的同學(xué)，這些代碼可能對(duì)實(shí)際生產(chǎn)中使用過MQ的同學(xué)，顯得太簡單了。

不過考慮到很多初學(xué)者可能連用都沒有用過MQ，甚至是才聽說消息中間件不久，所以筆者認(rèn)為這些demo代碼以及手工繪圖，還是很有必要。

好！看完了代碼，這個(gè)時(shí)候，我們可以通過一張圖來想象一下兩個(gè)服務(wù)之間的通信。

訂單服務(wù)你可以啟動(dòng)多個(gè)，不同的訂單服務(wù)都可以往一個(gè)RabbitMQ的queue里推送消息。

倉儲(chǔ)服務(wù)你也可以啟動(dòng)多個(gè)，多個(gè)倉儲(chǔ)服務(wù)會(huì)采用round-robin的輪詢算法，每個(gè)服務(wù)實(shí)例都可以從RabbitMQ queue里消費(fèi)到一部分的消息。

上面的圖里，訂單服務(wù)在MQ專業(yè)術(shù)語中叫做“生產(chǎn)者”，英文是“Producer”，意思就是這個(gè)服務(wù)是專門負(fù)責(zé)生產(chǎn)消息投遞到MQ的。

倉儲(chǔ)服務(wù)在MQ專業(yè)術(shù)語中叫做“消費(fèi)者”，英文是“Consumer”，意思就是這個(gè)服務(wù)專門是負(fù)責(zé)從MQ消費(fèi)消息然后處理的。

這個(gè)時(shí)候，這套異步通信的架構(gòu)就可以跑起來了。

好了，到目前為止，雖然這個(gè)代碼還存在不少問題，但是沒關(guān)系，大體上我們已經(jīng)給一些不太熟悉MQ技術(shù)的同學(xué)，從一個(gè)比較形象易于理解簡化后的電商業(yè)務(wù)場(chǎng)景出發(fā)，通過HelloWorld級(jí)別的示例代碼和手工繪圖，將MQ這個(gè)技術(shù)落地跑起來了。

更進(jìn)一步，各位同學(xué)完全可以參照這個(gè)文章里的案例，思考一下：自己負(fù)責(zé)的項(xiàng)目里，有沒有類似的業(yè)務(wù)場(chǎng)景可以使用MQ的？

然后想辦法在自己的項(xiàng)目里落地使用MQ的技術(shù)來做一下異步化，提升核心流程的性能。

這樣未來在跳槽面試的時(shí)候，才可以做到游刃有余，有自己的一套東西可以說。?