訊息佇列已經逐漸成為分布式應用場景、內部通信、以及秒殺等高并發業務場景的核心手段，它具有低耦合、可靠投遞、廣播、流量控制、最終一致性 等一系列功能，
無論是 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.訊息佇列的選型和應用場景
具體請參考：高并發架構系列：分布式之訊息佇列的特點、選型、及應用場景詳解
以上
作者簡介
陳睿|mikechen,10年+大廠架構經驗,《BAT架構技術500期》系列文章作者，分享十余年架構經驗以及面試心得!
閱讀mikechen的互聯網架構更多技術文章合集
Java并發|JVM|MySQL|Spring|Redis|分布式|高并發|架構師
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/509285.html
標籤：Java
上一篇：CTO 說了：誰再用 Redis 過期監聽實作定時任務，立馬滾蛋！
下一篇：Redis與Python連接實體