1. 訊息生產者、訊息者、佇列
2.設計broker主要考慮
1）訊息的轉儲：在更合適的時間點投遞，或者通過一系列手段輔助訊息最終能送達消費機。
2）規範一種正規化和通用的模式，以滿足解耦、最終一致性、錯峰等需求。
3）其實簡單理解就是乙個訊息**器，把一次rpc做成兩次rpc。傳送者把訊息投遞到broker，broker再將訊息**一手到接收端。
總結起來就是兩次rpc加一次轉儲，如果要做消費確認，則是三次rpc。
3. 點對點訊息佇列模型
點對點模型 用於 訊息生產者 和 訊息消費者 之間 點到點 的通訊。
點對點模式包含三個角色：
每個訊息都被傳送到乙個特定的佇列，接收者從佇列中獲取訊息。佇列保留著訊息，可以放在 記憶體 中也可以 持久化，直到他們被消費或超時。
特點
每個訊息只有乙個消費者（consumer）(即一旦被消費，訊息就不再在訊息佇列中)傳送者和接收者之間在時間上沒有依賴性接收者在成功接收訊息之後需向佇列應答成功
4. 發布訂閱訊息模型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.訊息佇列的選型和應用場景
具體請參考：高併發架構系列：分布式之訊息佇列的特點、選型、及應用場景詳解
本文由部落格一文多發平台 openwrite 發布！
高併發架構系列 MQ訊息佇列的12點核心原理總結
訊息佇列已經逐漸成為分布式應用場景 內部通訊 以及秒殺等高併發業務場景的核心手段，它具有低耦合 可靠投遞 廣播 流量控制 最終一致性等一系列功能。無論是 rabbitmq rocketmq activemq kafka還是其它等，都有的一些基本原理 術語 機制等，總結分享出來，希望大家在使用訊息佇列...
MQ 訊息佇列的概覽
目錄 前言 1.rocketmq對比kafka？rocketmq怎麼做到低延遲？2.主題和佇列有什麼區別？3.例外的訊息模型 rabbitmq 依然再用佇列的思想 4.rocketmq的訊息模型 5.kafka模型 6.總結 好的架構不是設計出來的，而是演進出來的。這個話很重要，也很有啟發。業務最適...
Windows訊息佇列MQ的使用
在系統間的進行資料傳遞，特別是資料量較大，分別插入不同的資料庫的時候。同時保證系統效率和響應時間，減少資料庫負擔的時候，使用訊息佇列是非常有幫助的。廢話不多說，直接上 把下面的 建為基類直接呼叫就可以了 using system.messaging 標頭檔案 using system using s...