原文連結：https://blog.csdn.net/lizhitao/article/details/51718156

背景
目前我們美團正在設計和不斷迭代、升級訊息中介軟體方案，為了避免走彎路，希望站在巨頭肩膀上，學習經驗、吸取精華，推動美團MQ快速演進，為美團業務高速擴張提供支撐

目標：可靠性（保證訊息不丟失）、非同步、解耦（無需同時線上、不需要知道對方是誰）。 
資料的儲存級別：記憶體中的資料（斷電丟資料）===》持久化磁碟（磁碟損壞）===》冗餘備份（一致性問題）

業界MQ設計方案如下：

1.阿里Notify架構

特點：
Notify之間不互相通訊。
支援水平擴充套件。
客戶端通過Config Server獲得Notify地址列表。
客戶端自動感知Notify的增加或減少。
釋出者、消費者、Notify Server都支援叢集。
訊息根據不同的安全級別選擇存放到不同的地方（如：File、Oracle、Mysql），然後放在記憶體中提高效能。
推模式
2.阿里RocketMQ架構
兩主兩從部署模式： 

特點：
Name Server無狀態節點，節點之間無任何資訊同步。
Broker與Name Server叢集中的所有節點建立長連線，定時註冊Topic資訊到所有Name Server。
Producer與Name Server中的其中一個節點建立長連線，定期獲取Topic路由資訊。
Consumer與Name Server中的其中一個節點建立長連線，定期從NameServer獲取Topic路由資訊。
拉模式 
3.騰訊-Tube架構 

特點：
Tube叢集使用了Zookeeper，目前主要用來儲存Consumer的消費位置和Master HA的選舉（歷史遺留問題，全新的Tube系統設計可以擺脫對ZK的依賴）
Broker向Master彙報自身資訊，包括自身id、狀態以及提供哪些Topic的釋出和訂閱服務，每個Topic下包含多少分割槽。
生產者和消費者向Master通報topic資訊，返回從哪些Broker獲取資料（客戶端自己做負載均衡）
Broker叢集節點之間通過心跳和Master保持狀態同步，當狀態發生變化時，Master會負責通知相關節點。
Master採用主備模式，通過ZK來進行選舉。
拉模式
4.騰訊-Hippo架構

特點：
三臺controller 一主兩備承擔整個系統節點資料的採集。（主備controller於心跳檢測，在主故障的時候自動failover）
三臺broker一主兩備組成一個組，主broker向controller定期彙報心跳以告知controller當前組的存活狀態。（主備broker之間存在心跳，主broker掛掉後，重新選舉，shuffle）
producer與controller之間存在心跳，獲取topic所在組的broker組的ip埠機器queue資訊。
consumer與controller之間存在心跳，獲取broker組資訊列表+同組其他消費者資訊列表。
限時鎖定：消費者拉取某個佇列的資料與確認回撥之間設定一個超時時間，一旦超時時間還沒確定，自動解鎖。
提供控制檯介面，根據當前收集到的正常執行的broker節點資訊，可以指定給某個特定的broker組下發topic及queue新增事件。
拉模式
5.攜程-Herms架構

* broker加入/退出，consumer加入/退出，parition的負載均衡。 
* metaserver通過zk發現broker，自己建立路由表，並分配給broker。 
* broker定時向meta server定時續lease。（通過zk做協調） 
* consumer儘量不直接連線zk，consumer到meta server獲取lease。（考慮到consumer量大，不通過zk做協調，直接和metaserver競爭lease） 
* 可通過meta server做直接干預（如機器出現問題）。 
* 長輪詢pull模式，早期使用推模式，broker需要寫的程式碼很複雜，而且一些高階特性不方便支援。

引用來自塗揚整理wiki
--------------------- 
作者：幽靈之使 
來源：CSDN 
原文：https://blog.csdn.net/lizhitao/article/details/51718156 
版權宣告：本文為博主原創文章，轉載請附上博文連結！