三分鐘瞭解RocketMQ與Kafka的異同
阿新 • • 發佈：2019-12-31
相同之處
- 兩者底層原理有很多相似之處，RocketMQ借鑑了Kafka的設計。
- 兩者均利用了作業系統Page Cache的機制，同時儘可能通過順序io降低讀寫的隨機性，將讀寫集中在很小的範圍內，減少缺頁中斷，進而減少了對磁碟的訪問，提高了效能。
不同之處
儲存形式
- Kafka採用partition，每個topic的每個partition對應一個檔案。順序寫入，定時刷盤。但一旦單個broker的partition過多，則順序寫將退化為隨機寫，Page Cache髒頁過多，頻繁觸發缺頁中斷，效能大幅下降。
- RocketMQ採用CommitLog+ConsumeQueue，單個broker所有topic在CommitLog中順序寫，Page Cache只需保持最新的頁面即可。同時每個topic下的每個queue都有一個對應的ConsumeQueue檔案作為索引。ConsumeQueue佔用Page Cache極少，刷盤影響較小。
儲存可靠性
- RocketMQ支援非同步刷盤，同步刷盤，同步Replication，非同步Replication。
- Kafka使用非同步刷盤，非同步Replication。
順序訊息
Kafka和RocketMQ都僅支援單topic分割槽有序。RocketMQ官方雖宣稱支援嚴格有序，但方式為使用單個分割槽。
延時訊息
- RocketMQ支援固定延時等級的延時訊息，等級可配置。
- kfaka不支援延時訊息。
訊息重複
- RocketMQ僅支援At Least Once。
- Kafka支援At Least Once、Exactly Once。
訊息過濾
- RocketMQ執行過濾是在Broker端，支援tag過濾及自定義過濾邏輯。
- Kafka不支援Broker端的訊息過濾，需要在消費端自定義實現。
訊息失敗重試
- RocketMQ支援定時重試，每次重試間隔逐漸增加。
- Kafka不支援重試。
DLQ（dead letter queue）
- RocketMQ通過DLQ來記錄所有消費失敗的訊息。
- Kafka無DLQ。Spring等第三方工具有實現，方式為將失敗訊息寫入一個專門的topic。
回溯消費
- RocketMQ支援按照時間回溯消費，實現原理與Kafka相同。
- Kafka需要先根據時間戳找到offset，然後從offset開始消費。
事務
- RocketMQ支援事務訊息，採用二階段提交+broker定時回查。但也只能保證生產者與broker的一致性，broker與消費者之間只能單向重試。即保證的是最終一致性。
- Kafka從0.11版本開始支援事務訊息，除支援最終一致性外，還實現了訊息Exactly Once語義（單個partition）。
服務發現
- RocketMQ自己實現了namesrv。
- Kafka使用ZooKeeper。
高可用
- RocketMQ在高可用設計上粒度只控制在Broker。其保證高可用是通過master-slave主從複製來解決的。
- Kafka控制高可用的粒度是放在分割槽上。每個topic的leader分割槽和replica分割槽都可以在所有broker上負載均衡的儲存。
- Kafka的這種設計相比RocketMQ這種主從複製的設計有以下好處：
- Kafka中不需要設定從broker，所有的broker都可以收發訊息。負載均衡也做的更好。
- Kafka的分割槽選舉是自動做的，RocketMQ需要自己指定主從關係。
- Kafka分割槽的複製份數指定為N，則可以容忍N-1個節點的故障。發生故障只需要分割槽leader選舉下即可，效率很高。