消息隊列已經逐漸成為分布式應用場景、內部通信、以及秒殺等高並發業務場景的核心手段，它具有低耦合、可靠投遞、廣播、流量控制、最終一致性 等一系列功能。
無論是 RabbitMQ、RocketMQ、ActiveMQ、Kafka還是其它等，都有的一些基本原理、術語、機制等，總結分享出來，希望大家在使用消息隊列技術的時候能夠快速理解。
1. 消息生產者、消息者、隊列
消息生產者Producer：發送消息到消息隊列
消息消費者Consumer：從消息隊列接收消息。
Broker：概念來自與Apache ActiveMQ，指MQ的服務端，幫你把消息從發送端傳送到接收端。
消息隊列Queue：一個先進先出的消息存儲區域。消息按照順序發送接收，一旦消息被消費處理，該消息將從隊列中刪除。
2.設計Broker主要考慮
1）消息的轉儲：在更合適的時間點投遞，或者通過一系列手段輔助消息最終能送達消費機。
2）規范一種范式和通用的模式，以滿足解耦、最終一致性、錯峰等需求。
3）其實簡單理解就是一個消息轉發器，把一次RPC做成兩次RPC。發送者把消息投遞到broker，broker再將消息轉發一手到接收端。
總結起來就是兩次RPC加一次轉儲，如果要做消費確認，則是三次RPC。
3. 點對點消息隊列模型
點對點模型 用於 消息生產者 和 消息消費者 之間 點到點 的通信。
點對點模式包含三個角色：
消息隊列（Queue）
發送者(Sender)
接收者(Receiver)
每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留着消息，可以放在 內存 中也可以 持久化，直到他們被消費或超時。
特點
每個消息只有一個消費者（Consumer）(即一旦被消費，消息就不再在消息隊列中)
發送者和接收者之間在時間上沒有依賴性
接收者在成功接收消息之后需向隊列應答成功
4. 發布訂閱消息模型Topic
發布訂閱模型包含三個角色：
主題（Topic）
發布者（Publisher）
訂閱者（Subscriber）
多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。
特點
每個消息可以有多個消費者：和點對點方式不同，發布消息可以被所有訂閱者消費
發布者和訂閱者之間有時間上的依賴性。
針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之后，才能消費發布者的消息。
為了消費消息，訂閱者必須保持運行的狀態。
5.點對點和發布訂閱的區別
生產者發送一條消息到隊列queue，只有一個消費者能收到。
發布者發送到topic的消息，只有訂閱了topic的訂閱者才會收到消息。
6. 消息的順序性保證
基於Queue消息模型，利用FIFO先進先出的特性，可以保證消息的順序性。
7. 消息的ACK機制
即消息的Ackownledge確認機制，
為了保證消息不丟失，消息隊列提供了消息Acknowledge機制，即ACK機制，當Consumer確認消息已經被消費處理，發送一個ACK給消息隊列，此時消息隊列便可以刪除這個消
息了。如果Consumer宕機/關閉，沒有發送ACK，消息隊列將認為這個消息沒有被處理，會將這個消息重新發送給其他的Consumer重新消費處理。
8.最終一致性的設計思路
主要是用“記錄”和“補償”的方式。
本地事務維護業務變化和通知消息，一起落地，然后RPC到達broker，在broker成功落地后，RPC返回成功，本地消息可以刪除。否則本地消息一直靠定時任務輪詢不斷重發，這樣就保證了消息可靠落地broker。
broker往consumer發送消息的過程類似，一直發送消息，直到consumer發送消費成功確認。
我們先不理會重復消息的問題，通過兩次消息落地加補償，下游是一定可以收到消息的。然后依賴狀態機版本號等方式做判重，更新自己的業務，就實現了最終一致性。
如果出現消費方處理過慢消費不過來，要允許消費方主動ack error，並可以與broker約定下次投遞的時間。
對於broker投遞到consumer的消息，由於不確定丟失是在業務處理過程中還是消息發送丟失的情況下，有必要記錄下投遞的IP地址。決定重發之前詢問這個IP，消息處理成功了嗎？如果詢問無果，再重發。
事務：本地事務，本地落地，補償發送。本地事務做的，是業務落地和消息落地的事務，而不是業務落地和RPC成功的事務。消息只要成功落地，很大程度上就沒有丟失的風險。
9. 消息的事務支持
消息的收發處理支持事務，例如：在任務中心場景中，一次處理可能涉及多個消息的接收、處理，這應該處於同一個事務范圍內，如果一個消息處理失敗，事務回滾，消息重新回到隊列中。
10. 消息的持久化
消息的持久化，對於一些關鍵的核心業務來說是非常重要的，啟用消息持久化后，消息隊列宕機重啟后，消息可以從持久化存儲恢復，消息不丟失，可以繼續消費處理。
11. 消息隊列的高可用性
在實際生產環境中，使用單個實例的消息隊列服務，如果遇到宕機、重啟等系統問題，消息隊列就無法提供服務了，因此很多場景下，我們希望消息隊列有高可用性支持，例如
RabbitMQ的鏡像集群模式的高可用性方案，ActiveMQ也有基於LevelDB+ZooKeeper的高可用性方案，以及Kafka的Replication機制等。
12.消息隊列的選型和應用場景
具體請參考：高並發架構系列：詳解分布式之消息隊列的特點、選型、及應用場景