前言
上一篇說明了一下，消息隊列的用處和使用場景。這篇給大家簡單介紹一下它的一些基本概念。
一、消息隊列的基本概念
1.1 Broker
Broker的概念來自與Apache ActiveMQ，通俗的講就是MQ的服務器。
1.2 消息生產者和消費者
- 消息生產者Producer：發送消息到消息隊列。
- 消息消費者Consumer：從消息隊列接收消息。
1.3 消息模型
點對點消息隊列模型
消息生產者向一個特定的隊列發送消息，消息消費者從該隊列中接收消息。
消息的生產者和消費者可以不同時處於運行狀態。
每一個成功處理的消息都由消息消費者簽收確認（Acknowledge）。如圖：
![]()
發佈訂閱消息模型-Topic
發佈訂閱消息模型中，支持向一個特定的主題Topic發佈消息，0個或多個訂閱者接收來自
這個消息主題的消息。在這種模型下，發佈者和訂閱者彼此不知道對方。實際操作過程中，
必須先訂閱，再發送消息，而後接收訂閱的消息，這個順序必須保證。
![]()
1.4 消息順序性保證
基於Queue消息模型，利用FIFO先進先出的特性，可以保證消息的順序性。
1.5 消息的ACK確認機制
即消息的Ackownledge確認機制：
爲了保證消息不丟失，消息隊列提供了消息Acknowledge機制，即ACK機制，當Consumer
確認消息已經被消費處理，發送一個ACK給消息隊列，此時消息隊列便可以刪除這個消息了。
如果Consumer宕機/關閉，沒有發送ACK，消息隊列將認爲這個消息沒有被處理，會將這個
消息重新發送給其他的Consumer重新消費處理。
1.6 消息的持久化
消息的持久化，對於一些關鍵的核心業務來說是非常重要的，啓用消息持久化後，消息隊列
宕機重啓後，消息可以從持久化存儲恢復，消息不丟失，可以繼續消費處理。
1.7 消息的同步和異步收發
- 同步
消息的收發支持同步收發的方式
同步收發場景下，消息生產者和消費者雙向應答模式，例如：張三寫封信送到郵局中轉站，
然後李四從中轉站獲得信，然後在寫一份回執信，放到中轉站，然後張三去取，當然張三
寫信的時候就得寫明回信地址。
消息的接收如果以同步的方式(Pull)進行接收，如果隊列中爲空，此時接收將處於同步阻
塞狀態，會一直等待，直到消息的到達。 - 異步
消息的收發同樣支持異步方式：異步發送消息，不需要等待消息隊列的接收確認。
異步接收消息，以Push的方式觸發消息消費者接收消息。
1.8 消息的事務支持
消息的收發處理支持事務，例如：在任務中心場景中，一次處理可能涉及多個消息的接收、
處理，這處於同一個事務範圍內，如果一個消息處理失敗，事務回滾，消息重新回到隊列中。
二、JMS消費服務
Java消息服務（Java Message Service，JMS）應用程序接口是一個Java平臺中關於面向
消息中間件（MOM）的API，用於在兩個應用程序之間，或分佈式系統中發送消息，進行異步通信。
點對點與發佈訂閱最初是由JMS定義的。
這兩種模式主要區別或解決的問題就是發送到隊列的消息能否重複消費(多訂閱)
JMS規範目前支持兩種消息模型：
- 點對點（point to point， queue）
- 發佈/訂閱（publish/subscribe，topic）
2.1 點對點：Queue，不可重複消費
消息生產者生產消息發送到queue中，然後消息消費者從queue中取出並且消費消息。
消息被消費以後，queue中不再有存儲，所以消息消費者不可能消費到已經被消費的消息。
Queue支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。
P2P模式包含三個角色：
- 消息隊列（Queue）
- 發送者(Sender)
- 接收者(Receiver)
每個消息都被髮送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留着消息，
直到他們被消費或超時。
2.2 發佈/訂閱：Topic，可以重複消費
消息生產者（發佈）將消息發佈到topic中，同時有多個消息消費者（訂閱）消費該消息。
和點對點方式不同，發佈到topic的消息會被所有訂閱者消費。
支持訂閱組的發佈訂閱模式：
發佈訂閱模式下，當發佈者消息量很大時，顯然單個訂閱者的處理能力是不足的。實際上現實
場景中是多個訂閱者節點組成一個訂閱組負載均衡消費topic消息即分組訂閱，這樣訂閱者很
容易實現消費能力線性擴展。可以看成是一個topic下有多個Queue，每個Queue是點對點的
方式，Queue之間是發佈訂閱方式。
2.3 區別
- 點對點模式
生產者發送一條消息到queue，一個queue可以有很多消費者，但是一個消息只能被一個消費者
接受，當沒有消費者可用時，這個消息會被保存直到有一個可用的消費者，所以Queue實現了
一個可靠的負載均衡。 - 發佈訂閱模式
發佈者發送到topic的消息，只有訂閱了topic的訂閱者纔會收到消息。topic實現了發佈和訂閱，
當你發佈一個消息，所有訂閱這個topic的服務都能得到這個消息，所以從1到N個訂閱者都能得到
這個消息的拷貝。
三、流行模型對比
傳統企業型消息隊列ActiveMQ遵循了JMS規範，實現了點對點和發佈訂閱模型，但其他流行的
消息隊列RabbitMQ、Kafka並沒有遵循JMS規範。
3.1 RabbitMQ
RabbitMQ實現了AQMP協議，AQMP協議定義了消息路由規則和方式。生產端通過路由規則發送消息
到不同queue，消費端根據queue名稱消費消息。
RabbitMQ既支持內存隊列也支持持久化隊列，消費端爲推模型，消費狀態和訂閱關係由服務端負責
維護，消息消費完後立即刪除，不保留歷史消息。
點對點
生產端發送一條消息通過路由投遞到Queue，只有一個消費者能消費到。
![]()
多訂閱
當RabbitMQ需要支持多訂閱時，發佈者發送的消息通過路由同時寫到多個Queue，不同訂閱組消費
不同的Queue。所以支持多訂閱時，消息會多個拷貝。
![]()
3.2 Kafka
Kafka只支持消息持久化，消費端爲拉模型，消費狀態和訂閱關係由客戶端端負責維護，
消息消費完後不會立即刪除，會保留歷史消息。因此支持多訂閱時，消息只會存儲一份
就可以了。但是可能產生重複消費的情況。
參考文章:
https://blog.csdn.net/heyutao007/article/details/50131089
https://www.cnblogs.com/tianqing/p/7110468.html