一男子激動地安裝了RabbitMQ，看完博文後笑容沒了

一個事物老是會關聯着不少事物。

要了解RabbitMQ，先了解 AMQP，要了解AMQP，先了解MQ。

（1）MQ 

Message Queue 消息隊列，簡稱MQ，用於跨進程之間的上下游非實時通訊。此處的上下游是平行關係。
MQ適用場景：上下游之間須要進行低頻、非實時通訊、上下游之間業務不相互依賴。
MQ不適用場景：高頻、實時、上下游相互依賴、耦合。此時用方法調用的方式。（方法調用或遠程調用）。
MQ是一種技術的統稱。

（2） AMQP

一種應用層協議，專用用於消息通訊，算是一個RFC標準（HTTP1.1 定義在RFC2616中）。應用層協議不須要了解太多。只須要了解OSI七層模型中，TCP和UDP 位於傳輸層，基於TCP/UDP之上的協議後來都是應用層協議。
這些協議的區別在我看來無非就是長鏈接、短連接，報文協議格式不一樣而已。既如此，理解HTTP就夠了。AMQP、RSTP、MQTT、FTP、WebSocket、SMTP... 這些協議，有需求再去理解。通常也不用去理解，會有對應的框架和技術來屏蔽各類協議，讓你面向對象或者面向API開發。

AMQP是一種通訊協議。

（3）RabbitMQ

Tomcat，Nginx，Apache 都按照HTTP協議去實現，因此它們的相同點就是都是HTTP服務器。RabbitMQ是一種實現了AMQP協議的軟件程序。天然叫作消息服務器。和HTTP服務器相似，通訊雙方一個叫作客戶端，一個叫作服務端。只不過在RabbitMQ是一種專門用於接受消息的服務器。而它們接受消息的目的，是爲了暫時保存、以便其它客戶端獲取，因此RabbitMQ服務端的確是一個消息中轉站，負責接受和保存消息。而RabbitMQ客戶端，咱們之前稱之爲上下游。如今咱們給它一個更具體的名稱：生產者 或者消費者。產生消息的客戶端就是生產者、拿走消息的客戶端就是消費者。

舉個例子：
如今有兩個系統：一個是開獎系統A、一個是其餘業務系統B。開獎系統只負責開獎，可是考慮到別人可能須要知道開獎結果，因此A產生一個消息放到中轉站中，業務系統B從中中轉站拿走這個消息。 這個場景，就適合用RabbitMQ。A系統就是上游，就是消息生產者。中轉站就是RabbitMQ，接受消息的地方。B系統就是下游，就是消費者，從中轉站中拿走消息。A不依賴於B，B不依賴於A，二者之間的通訊既不用那麼實時、高頻，也不是相互依賴。RabbitMQ這個中間件起的就是一個解耦的做用。

至此，對RabbitMQ已有大概認識。RabbitMQ 是消息服務器、有消息存儲功能，提供了算法實現。其餘客戶端只須要把消息放在這，或者從這拿走消息就好了。

（4） 如何使用RabbitMQ（沒有具體的代碼，只是粗略的步驟而已。）
    首先要搭建RabbitMQ服務器。
            去官網下載軟件，安裝，啓動服務。沒錯就像安裝mysql、redis、apache那樣。有配置文件吧，也許。但我目前還不知道。由於沒具體學習。
    其次生產者系統要在須要發消息的時候產生消息發給RabbitMQ服務器
            發消息，確定要是客戶端乾的事情。若是是java語言，去找對應的maven依賴。若是是node.js，去找對應的npm包。
            而後創建鏈接，發消息就好了。創建鏈接是須要帳號、密碼、虛擬機等這些信息的。而後就是用不一樣的工做模式的調用API發消息。
            RabbitMQ就會收到消息。
    與此同時消費者系統要 開啓監聽，等待消息從RabbitMQ服務器的到來
             相似同上步驟，選擇語言、包，創建鏈接。而後就是監聽消息。
            

（5）  RabbitMQ工做模式

RabbitMQ提供了各類編程語言的客戶端支持。對java來講，RabbitMQ客戶端就是一個jar。使用java的RabbitMQ客戶端開發包能夠，
把消費發送給RabbitMQ服務器-------生產者。
還能夠經過監聽，接受RabbitMQ那裏的消息（賭一包辣條，底層是TCP長鏈接實現的全雙工） ------------消費者。

在學習多線程的時候，就已經模擬過生產者和消費者的場景了。要麼一個生產者、一個消費者，要麼是一個生產者，多個消費者。。。狀況比較多，
RabbitMQ也會面臨這樣的選擇，RabbitMQ的工做模式：（從CSDN借用一個圖 https://blog.csdn.net/hellozpc/article/details/81436980  ）

簡單模式：一個生產者，一個消費者
work模式：一個生產者，多個消費者，每一個消費者獲取到的消息惟一。
訂閱模式：一個生產者發送的消息會被多個消費者獲取。
路由模式：發送消息到交換機而且要指定路由key ，消費者將隊列綁定到交換機時須要指定路由key
topic模式：將路由鍵和某模式進行匹配，此時隊列須要綁定在一個模式上，「#」匹配一個詞或多個詞，「*」只匹配一個詞。
RPC模式：

 

（6） 個人需求

現有 應用系統A、應用系統B、底層硬件系統C。 A依賴於B的數據，但不和C發生直接通訊，B和C之間經過4G模塊進行頻繁、實時通訊。數據量有的比較大、有的比較少。 B的確須要一些中間件來緩存一些實時數據（一小段時間內不覆蓋，長時間覆蓋），在A須要的時候可從B這裏拿，實現間接的實時。有可能有人會有疑問，爲何須要B？把B剔除掉，A和C通訊不就完事了嗎？ 的確如此。但是A已經開發好，由甲方開發。B和C由乙方開發。個人最終的方案和目標是：把B開發出來，做爲一個子系統給A去調用（A的先後臺均可能會調用B）。也就是分佈式系統。 綜上，RabbitMQ並不能解決個人問題。因此我沒有系統學習它。而是花了幾個小時的時間大概瞭解了它，而後寫下了這篇博文。