大家在學習過程可能經常會看到"消息隊列"、“RabbitMQ”、"Kafka"等等這些詞。反正我關注的挺多公衆號會推送這些的相關文章，但是還沒有到那種應用場景，所以就沒有去額外關注。最近剛剛好學習了一些有關消息隊列的知識，就來記錄一下
消息隊列是個啥
消息隊列其實是一個消息的容器。它的底層是一個隊列(Queue)的數據結構，它滿足先進先出的原則。也就是說先進來的消息先出去，後進來後出去。這樣消息被消費時，大致有個順序可言。
基於消息隊列的架構大致是這樣的，瀏覽器發出某個請求，由生產者生成消息，並進入到消息隊列中，等待消息接受者來接受並處理。在等待的過程中，先把結果先返回給瀏覽器(比如註冊賬戶時，先把消息放入消息隊列中，然後把"註冊成功"的消息返回給瀏覽器)，而不是先處理它。在消息接受者接受消息後，編寫相應的程序去處理它，最後如果有需要再把這個處理結果放到消息隊列，等待別的消息接受者進行二次處理。
消息隊列的各個概念解釋
消息發送者(publisher)：也叫做消息生產者，是消息發送的源頭
消息接受者(consumer):接受消息並進行處理的程序，也叫做消息的消費者，它們在處理完消息
消息代理(message broker):當消息發送者發送消息以後，將由消息代理接管，消息代理保證消息傳遞到指定目的地。
目的地(destination):顧名思義，消息要發送到的地方,而目的地又大致分爲兩種方式，點對點式(point to point)與主題式(topic)
-
點對點式：
消息發送者發送消息，消息代理將其放入一個隊列中，消息接收者從隊列中獲取消息內容，消息讀取後被移出隊列
消息只有唯一的發送者和接受者，但並不是說只能有一個接收者 -
主題式:
這種方式也稱爲發佈訂閱式。
發送者（發佈者）發送消息到主題，多個接收者（訂閱者）監聽（訂閱）這個主題，那麼就會在消息到達時同時收到消息
消息的協議規範:現在市面大致有兩種有關消息的規範,JMS與AMQP，這兩個就相當於jdbc對操作數據庫而言。
- JMS：JAVA消息服務，基於JVM消息代理的規範。ActiveMQ、HornetMQ是JMS實現
- AMQP（Advanced Message Queuing Protocol）
高級消息隊列協議，也是一個消息代理的規範，兼容JMS
RabbitMQ是AMQP的實現
兩者的區別:
RabbitMQ簡介與概念
RabbitMQ簡介：
RabbitMQ是一個由erlang開發的AMQP(Advanved Message Queue Protocol)的開源實現。它是AMQP協議的實現類
一些概念：
-
Message
消息，消息是不具名的，它由消息頭和消息體組成。消息體是不透明的，而消息頭則由一系列的可選屬性組成，這些屬性包括routing-key（路由鍵）、priority（相對於其他消息的優先權）、delivery-mode（指出該消息可能需要持久性存儲）等。其中routing-key(路郵鍵)挺重要的，決定了進入哪一個消息隊列。 -
Exchange
交換器，用來接收生產者發送的消息並將這些消息路由給服務器中的隊列。
Exchange有4種類型：direct(默認)，fanout, topic, 和headers，不同類型的Exchange轉發消息的策略有所區別,第一種類型就是之前提到的點對點式，後面三種是主題式的細分。 -
Queue
消息隊列，用來保存消息直到發送給消費者。它是消息的容器，也是消息的終點。一個消息可投入一個或多個隊列。消息一直在隊列裏面，等待消費者連接到這個隊列將其取走。 -
Binding
綁定，用於消息隊列和交換器之間的關聯。一個綁定就是基於路由鍵將交換器和消息隊列連接起來的路由規則，所以可以將交換器理解成一個由綁定構成的路由表。
Exchange 和Queue的綁定可以是多對多的關係。一個Exchange可以綁定多個Queue，同理Queue也是一樣 -
Connection
網絡連接，比如一個TCP連接。 -
Channel
信道，多路複用連接中的一條獨立的雙向數據流通道。信道是建立在真實的TCP連接內的虛擬連接，AMQP 命令都是通過信道發出去的，不管是發佈消息、訂閱隊列還是接收消息，這些動作都是通過信道完成。因爲對於操作系統來說建立和銷燬 TCP 都是非常昂貴的開銷，所以引入了信道的概念，以複用一條 TCP 連接。
簡單來說，信道所有的消息傳輸都是用同一個連接來傳輸數據，而不同的消息傳輸則是在連接中走不同的"路"。 -
Virtual Host
虛擬主機，表示一批交換器、消息隊列和相關對象。虛擬主機是共享相同的身份認證和加密環境的獨立服務器域。每個 vhost 本質上就是一個 mini 版的 RabbitMQ 服務器，擁有自己的隊列、交換器、綁定和權限機制。vhost 是 AMQP 概念的基礎，必須在連接時指定，RabbitMQ 默認的 vhost 是 / 。 -
Broker
表示消息隊列服務器實體
它們之間的關係爲：
消息隊列的應用場景:
它的應用場景主要就是流量削峯和應用解藕。
首先來談談流量削峯，在上文講解消息隊列時就說過它的架構模式，消息代理在接受到消息，先給瀏覽器返回處理結果信息。這麼做有一個好處，就是讓用戶看到的響應速度變快了。用一個比喻講就是，有一個人來請求我辦事，我思考了一下可不可以幫，發現可以之後先答應你，之後在慢慢做。平時在一些高併發的場景下，短時間會有大量的訪問量，而使用傳統的架構模式容易導致宕機，使用基於消息隊列的架構模式，先接受消息請求，響應完成後在處理，消息的讀取速度遠遠快於數據庫的讀取速度，這樣就起到了流量削峯的目的。同時它還支持多個消息隊列，這樣還可以多隊列消息訪問，速度會更快。
應用解藕：
消息隊列使利用發佈-訂閱模式工作，消息發送者（生產者）發佈消息，一個或多個消息接受者（消費者）訂閱消息。 消息發送者將消息發送至分佈式消息隊列即結束對消息的處理，消息接受者從分佈式消息隊列獲取該消息後進行後續處理，並不需要知道該消息從何而來。對新增業務，只要對該類消息感興趣，即可訂閱該消息，對原有系統和業務沒有任何影響，從而實現網站業務的可擴展性設計。這樣也就達成了應用解藕的目的。
記得有一點點雜亂，如果有一些錯誤，歡迎各位指出