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

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

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

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

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

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

這是為啥呢？

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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