一、場景引入，問題初現

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

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

然后系統就這么上線了，一開始業務復雜度低，用戶規模小，系統上線一段時間，注冊用戶量 5萬+，日活平均 1 千用戶。

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

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

這是為啥呢？

• 推送的業務場景多樣，多表關聯。
• 項目數據庫還沒有設計好索引，或者是設計了索引，但無奈負責該模塊的小弟采用串行編碼，導致整方法執行完，等待時間過長。

二、揚湯止沸，飲鴆止渴

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

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

三、追本溯源，治標治本

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

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

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

終于系統上線，運營人員反饋該功能體驗很好，為他們節省了大量時間。

四、總結全文，回眸再看

本文主要是針對實戰業務中場景出現的實際問題，從系統架構上進行優化，引入MQ幫助系統進行消息的傳輸功能， 從而讓各個服務只關注各自的實現，達到系統解耦的功效；另一方面主要是提高了系統性能，保證系統的穩定運行，讓用戶體驗更好。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。