RabbitMQ是2007年發布，是壹個在AMQP(高級消息隊列協議)基礎上完成的，簡稱MQ全稱為Message Queue, 消息隊列（MQ）是壹種應用程序對應用程序的通信方法，由Erlang（專門針對於大數據高並發的語言）語言開發，可復用的企業消息系統，是當前最主流的消息中間件之壹，具有可靠性、靈活的路由、消息集群簡單、隊列高可用、多種協議的支持、管理界面、跟蹤機制以及插件機制。
1.消息 就是數據，增刪改查的數據。例如在員工管理系統中增刪改查的數據
2.隊列 指的是壹端進數據壹端出數據，例如C#中(Queue數據結構）
1.消息隊列指：壹端進消息，壹端出消息
2.RabbitMQ就是實現了消息隊列概念的壹個組件，以面向對象的思想去理解，消息隊列就是類，而RabbitMQ就是實例，當然不僅僅只有RabbitMQ,例如ActiveMQ，RocketMQ，Kafka，包括Redis也可以實現消息隊列。
1.在常見的單體架構中，主要流程是用戶UI操作發起Http請求>服務器處理>然後由服務器直接和數據庫交互，最後同步反饋用戶結果
2.在微服務架構中，UI與微服務通信，主要是通過Http或者gRPC同步通信
問題分析
在上述2種情況下，我們發現在UI請求時都是同步操作 ，第2種架構雖然將整體服務按業務拆分成不同的微服務並且對應各自的數據庫，但是在用戶與微服務通信時，存在的問題依然沒有解決，例如數據庫的承載能力只能處理10w個請求，如果遇到高並發情況下，UI發起50w請求，那數據庫是遠遠承載不了的,從而導致如下問題。
1.高並發請求導致系統性能下降響應慢，同時數據庫承載風險加大
2.擴展性不強UI操作的交互對業務的依賴較大，導致用戶體驗下降
3.瞬時流量湧入巨大的話，服務器可能直接掛了
解決方案
RabbitMQ的優勢
RabbitMQ的不足
1.ConnectionFactory 為Connection的制造工廠。
2.Connection是RabbitMQ的socket鏈接，它封裝了socket協議相關部分邏輯。
3.Channel是我們與RabbitMQ打交道的最重要的壹個接口，我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發布消息等。
4.Exchange（交換機） 我們通常認為生產者將消息投遞到Queue中，實際上實際的情況是，生產者將消息發送到Exchange，由Exchange將消息路由到壹個或多個Queue中（或者丟棄），而在RabbitMQ中的Exchange壹***有4種策略，分別為：fanout（扇形）、direct（直連）、topic（主題）、headers（頭部）
1.下載RabbitMQ
2.運行環境erlang
3.安裝完成之後，加載RabbitMQ管理插件
4.安裝成功訪問RabbitMQ管理後臺blogs.com/yuxl01/p/15978229.html