目標：可靠性（保證消息不丟失）、異步、解耦（無需同時在線、不需要知道對方是誰）。
數據的存儲級別：內存中的數據（斷電丟數據）=》持久化磁盤（磁盤損壞）=》冗余備份（一致性問題）

業界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需要寫的代碼很復雜，而且一些高級特性不方便支持。

總結

以上是生活随笔為你收集整理的腾讯 VS 阿里 VS 携程消息中间件设计方案及思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。