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