鏈接：https://zhuanlan.zhihu.com/p/60196818
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
（1） 適用場景
Kafka適合日志處理；
RocketMQ適合業務處理。
結論：平手，根據具體業務定奪。
（2） 性能
Kafka單機寫入 TPS 號稱在百萬條/秒；
RocketMQ 大約在10萬條/秒。
結論：追求性能的話，Kafka單機性能更高。
（3） 可靠性
RocketMQ支持異步/同步刷盤;異步/同步Replication；
Kafka使用異步刷盤方式，異步Replication。
結論：RocketMQ所支持的同步方式提升了數據的可靠性。
（4） 實時性
均支持pull長輪詢，RocketMQ消息實時性更好
結論：RocketMQ 勝出。
（5） 支持的隊列數
Kafka單機超過64個隊列/分區，消息發送性能降低嚴重；
RocketMQ 單機支持最高5萬個隊列，性能穩定
結論：長遠來看，RocketMQ 勝出，這也是適合業務處理的原因之一
（6） 消息順序性
Kafka 某些配置下，支持消息順序，但是一台Broker宕機后，就會產生消息亂序；
RocketMQ支持嚴格的消息順序，在順序消息場景下，一台Broker宕機后，
發送消息會失敗，但是不會亂序；
結論：RocketMQ 勝出
（7）消費失敗重試機制
Kafka消費失敗不支持重試
RocketMQ消費失敗支持定時重試，每次重試間隔時間順延。
（8）定時/延時消息
Kafka不支持定時消息；
RocketMQ支持定時消息
（9）分布式事務消息
Kafka不支持分布式事務消息；
阿里雲ONS支持分布式定時消息，未來開源版本的RocketMQ也有計划支持分布式事務消息
（10）消息查詢機制
Kafka不支持消息查詢
RocketMQ支持根據Message Id查詢消息，也支持根據消息內容查詢消息
（11）消息回溯
Kafka理論上可以按照Offset來回溯消息
RocketMQ支持按照時間來回溯消息，精度毫秒，例如從一天之前的某時某分某秒開始重新消費消息
3. 為什么阿里會自研RocketMQ？
（1）Kafka的業務應用場景主要定位於日志傳輸；對於復雜業務支持不夠
（2）阿里很多業務場景對數據可靠性、數據實時性、消息隊列的個數等方面的要求很高。
kafka針對海量數據，但是對數據的正確度要求不是十分嚴格。而阿里巴巴中用於交易相關的事情較多，對數據的正確性要求極高，Kafka不合適
（3）當業務成長到一定規模，采用開源方案的技術成本會變高.
開源方案無法滿足業務的需要；舊版本、自開發代碼與新版本的兼容都可能是問題；運維角度，Kafka使用 scala 編寫，而阿里是java系。Kafka 的后續維護是個問題。
（4）阿里在團隊、成本、資源投入等方面約束性條件幾乎沒有.
綜上，阿里選擇自己開發RocketMQ更多是業務的驅動，當業務更多的需要以下功能的支持時，kafka 不能滿足或者 ActiveMQ 等其他消息中間件不能滿足，財大氣粗能力又強業務還復雜，所以就自己開發了。
4. 其他
另外認為kafka是用於日志傳輸，所以不適合系統的業務事件是個更大的誤區，Kafka本身在最早實現時的確是為了傳輸日志，但后來經過多年發展，其適用范圍早不限於日志，並且很多采取Kafka的公司並非用它來處理日志，kafka背后的 Confluence公司提供了很多基於kafka來簡化系統實現的例子。