一、場景引入，問題初現(xiàn)

很多讀者期待的是先講段理論、原理啥的，然而我的寫文章的邏輯習(xí)慣性的是想將問題的背景引入，用真實的案例來尋尋漸進(jìn)。

我的老上家是一家創(chuàng)業(yè)型的B2B方向建材互聯(lián)網(wǎng)企業(yè)，從 0 到 1 組建了一支10 人的小型研發(fā)團(tuán)隊。在入職的第二天被告知要在一個半月內(nèi)上線WEB網(wǎng)站和APP兩個端項目，項目啟動的時候我們就兩個JAVA，我們商量著如何啟動項目，如何快速進(jìn)入開發(fā)，快速完成任務(wù)。最終我們選用了SpringBoot + Dubbo 架構(gòu)來進(jìn)行開發(fā)。一段時間沒日沒夜的加班，好不容易核心業(yè)務(wù)系統(tǒng)給做出來了，平時正常QA測試沒發(fā)現(xiàn)什么大毛病，感覺性能還不錯，一切都很完美。

然后系統(tǒng)就這么上線了，一開始業(yè)務(wù)復(fù)雜度低，用戶規(guī)模小，系統(tǒng)上線一段時間，注冊用戶量 5萬+，日活平均 1 千用戶。

每天都有新的數(shù)據(jù)進(jìn)入數(shù)據(jù)庫的表中，就這么日積月累的，沒想到數(shù)據(jù)規(guī)模居然慢慢吞吞增長到了單表幾百萬。

這個時候呢，看起來也沒太大的毛病，就是有運(yùn)營人員反應(yīng)，文章推送功能反應(yīng)比較慢，頁面上的 loading 要轉(zhuǎn)個 10 來分鐘才消失。

這是為啥呢？

• 推送的業(yè)務(wù)場景多樣，多表關(guān)聯(lián)。
• 項目數(shù)據(jù)庫還沒有設(shè)計好索引，或者是設(shè)計了索引，但無奈負(fù)責(zé)該模塊的小弟采用串行編碼，導(dǎo)致整方法執(zhí)行完，等待時間過長。

二、揚(yáng)湯止沸，飲鴆止渴

一般碰到這種事情，一大堆代碼性能問題，80%的工程師首先想到的大多是采用多線程進(jìn)行編碼。

后來仔細(xì)梳理現(xiàn)有業(yè)務(wù)場景，很多場景需要做消息的傳遞工作，這個時候就想著有什么方式能進(jìn)行消息的傳遞工作，自然而然選擇引入消息隊列。

三、追本溯源，治標(biāo)治本

考慮消息中間件的引入主要是保證系統(tǒng)的可用性，所以消息隊列的引入很好的解決了系統(tǒng)的性能問題。

引入消息隊列后，整體流程如圖所示。
同樣的功能，將業(yè)務(wù)邏輯分到三個系統(tǒng)處理：

• 文章推送服務(wù)只需要對文章進(jìn)行保存，然后將文章ID Provider 到 MQ 的 new_article 隊列中。
• 業(yè)務(wù)查詢服務(wù)主要是 Consumerr MQ 中 new_article 隊列中各種條件進(jìn)行篩選聚合，并叫結(jié)果 Provider 到 MQ 的 push_article 隊列中。
• 消息推送服務(wù)主要是 Consumer MQ 中 push_article 隊列中用戶集合進(jìn)行push。

終于系統(tǒng)上線，運(yùn)營人員反饋該功能體驗很好，為他們節(jié)省了大量時間。

四、總結(jié)全文，回眸再看

本文主要是針對實戰(zhàn)業(yè)務(wù)中場景出現(xiàn)的實際問題，從系統(tǒng)架構(gòu)上進(jìn)行優(yōu)化，引入MQ幫助系統(tǒng)進(jìn)行消息的傳輸功能， 從而讓各個服務(wù)只關(guān)注各自的實現(xiàn)，達(dá)到系統(tǒng)解耦的功效；另一方面主要是提高了系統(tǒng)性能，保證系統(tǒng)的穩(wěn)定運(yùn)行，讓用戶體驗更好。

總結(jié)

以上是生活随笔為你收集整理的rabbitmq实战_RabbitMQ 实战系列之：消息传递的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。