訊息佇列已經逐漸成為分布式應用場景、內部通訊、以及秒殺等高併發業務場景的核心手段，它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能。
無論是 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,系統將這些訊息傳遞給多個訂閱者。
特點
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.訊息佇列的選型和應用場景
具體請參考：高併發架構系列：詳解分布式之訊息佇列的特點、選型、及應用場景，更多優質內容，推薦群179961551了解，本號專注技術學習交流、分享面試機會，我會不定期回答群內問題~
以上是就是訊息佇列mq技術的一些梳理和歸納，希望對大家有幫助。
覺得不錯請點贊支援，更多分享，檢視我往期博文~
1 選擇訊息佇列MQ
更快的返回結果。減少等待，實現了步驟之間的併發，提公升系統整體效能。使用訊息佇列隔離閘道器和後端服務，以達到流量控制和保護後端服務的目的。秒殺開始後，當短時間內大量的秒殺請求到達閘道器時，不會直接衝擊到後端的秒殺服務，而是先堆積在訊息佇列中，後端服務按照自己的最大處理能力，從訊息佇列中消費請求進行處...
高併發架構設計原則 訊息佇列
解耦 消峰 非同步 有abcd四個系統，a系統有一條資料需要傳給bcd，a系統不僅要關心資料傳送還要處理資料傳送bcd其中產生的異常，如b掛掉了怎麼辦，a是否重傳？如果使用訊息佇列，a系統只負責傳送訊息到訊息佇列，bcd消費訊息佇列中的訊息即可，a系統不關心訊息發給誰了，誰消費失敗了等等問題。類似於...
訊息佇列處理高併發
用mq來將耗時比較長或者耗費資源的請求排隊，非同步處理，減輕伺服器壓力增加穩定性。如果是高併發的實時請求，我個人覺得不適用這個方案。如果是為了高併發，我覺得應該朝解決高併發的方向考慮。集群 分布式 動靜分離 資料庫讀寫分離之類的。web的話，只能客戶端頁面輪訓處理結果。因為，據我個人了解啊，現在we...