RabbitMQ的具體概念，百度百科一下，我這里說一下我的理解，如果有少或者不對的地方，歡迎糾正和補充。
一個項目架構(gòu)，小的時候，一般都是傳統(tǒng)的單一網(wǎng)站系統(tǒng)，或者項目，三層架構(gòu)，到現(xiàn)在的MVC架構(gòu)。隨著用戶訪問量越來越多，系統(tǒng)業(yè)務(wù)越來越多，會出現(xiàn)以下問題：
1.修改完大量代碼后，不敢更新，因為都是集成在一起，互相耦合性非常強，一處報錯，滿盤皆掛；
2.整個項目文件夾，層級越來越多，對新來的同事很不友好，文件不可避免的會亂放，重復(fù)的過多，甚至為了緊急更新，會把很多原本的需要編譯的代碼，挪到一般處理程序中，
時間越長，越會發(fā)現(xiàn)，整個代碼結(jié)構(gòu)像一鍋粥一樣；
3.會有很多地方需要記錄日志，郵件，短信等等很多需要異步的操作，如果訪問量過高，會把這個系統(tǒng)拖垮。
上述問題出現(xiàn)一定時間后，一定會重構(gòu)整個，進行業(yè)務(wù)分離，SOA架構(gòu)服務(wù)化，這就涉及到多個應(yīng)用相互之間的通信，常見的方式，是通過API的方式通過JSON的方式，進行數(shù)據(jù)交互，
這種做法實時性很高，但是對單個業(yè)務(wù)系統(tǒng)的高峰期壓力還是非常大的，需要對但業(yè)務(wù)API系統(tǒng)進行負載均衡，這時候，如果說把一些要求實時性相對低一些，并且特別消耗性能的請求，摘出去慢慢處理的話，消息隊列就派上用場了，引入的消息隊列就成了消息處理的緩沖區(qū)。消息隊列引入的異步通信機制，使得發(fā)送方和接收方都不用等待對方返回成功消息，就可以繼續(xù)執(zhí)行下面的代碼，從而提高了數(shù)據(jù)處理的能力。尤其是當訪問量和數(shù)據(jù)流量較大的情況下，就可以結(jié)合消息隊列與后臺任務(wù)，通過避開高峰期對大數(shù)據(jù)進行處理，就可以有效降低數(shù)據(jù)庫和程序處理數(shù)據(jù)的負荷。
延伸閱讀
學(xué)習是年輕人改變自己的最好方式