我們知道，阿里的RocketMQ其實源自Kafka。同時網路上一直流傳著1篇阿里中介軟體團隊所寫的RocketMQ與Kafka的18項差異的文章，並且被廣泛轉發。比如：
http://blog.csdn.net/damacheng/article/details/42846549

作為對Kafka有一點研究的愛好者，認為這18項差異有“斷章取義”之嫌。本著嚴禁的科學精神，本文試圖對這18個條款進行逐一剖析。有不正確之處，歡迎批評指正。

有興趣朋友可以關注公眾號“架構之道與術”， 獲取最新文章。
或掃描如下二維碼：

差異之1–”資料可靠性”問題

(1)Kafka只支援非同步replication？

結論：Kafka不僅支援非同步replication，也支援同步replication，也就是：等訊息同步到所有副本之後，再返回給客戶端成功。

具體細節，可以參考我之前寫的Kakfa原始碼分析序列，配置ack引數即可實現同步複製。

(2)Kafka只支援非同步刷盤？

結論：預設Kafka是非同步刷盤，每3s鍾，呼叫1次fsync。但Kafka支援同步刷盤，也就是說，你可以每寫入1條訊息，就刷盤1次。

具體細節，參考我寫的Kafka原始碼分析序列，Log檔案結構和刷盤原理那1節。同樣，也是配置一個log的引數即可。

(3)Kafka的可靠性解決辦法–叢集思路

那為什麼Kafka預設使用了非同步刷盤呢，不怕丟資料嗎？其實不是。

Kafka其實是用叢集的思路，每個topic_partition多個備份（你可以保證這多個備份是完全一致的）。一臺機器掛了，因為資料在page cache裡面，會丟；但多個備份同時掛的可能性，就很小了。

所以關於“可靠性”的對比，不能光是“單機”的思路。

差異之2– “效能問題“

原文之中比較kafka和RocketMQ的效能的時候，個人認為不是在一個維度上比較。

要比較效能，不能1個是“同步複製”，一個是“非同步複製”來比較，這樣沒有可比性。

要比較，大家都“同步複製”“同步刷盤”；或者大家都“非同步複製”，“非同步刷盤”來比。

因為“效能”和“可靠性”本來就是一對權衡的因素，不能犧牲一個，來比另一個。

差異之3 – “訊息投遞實時性”

Kafka從0.8以後，就開始支援long pull。所以在實時性上，2者並無差別。

差異之4 – “消費失敗重試”

這個也就是exactly once問題，關於這個，我在Kafka原始碼分析的序列1中，就有探討。

關於這個問題，Kafka的確不處理，而是讓消費的業務方去處理，並給出了相應的解決方案。

差異之5 – “嚴格的訊息順序”

原文中說：“卡夫卡支援訊息順序，但是一臺代理宕機後，就會產生訊息亂序”。

個人認為這個是斷章取義，如果你是非同步複製，可能亂序。

但對於同1個partition，只要你是同步複製，該partition在多個副本上，是完全一致的。一個宕機，切換到另一個，不會產生訊息亂序。

其他

其他諸如“事務訊息”，“定時訊息“，“訊息查詢”，“訊息軌跡”，”按時間的訊息回朔“，這些Kafka的確沒有。

個人認為這些功能可能是RocketMQ針對“電商”的特定業務場景所產生的，而Kafka沒有這麼強的業務針對性，所以沒有考慮這些特定功能。

但沒有這些特定功能，不代表業務方不能自己解決這些問題。只是說，針對這些特定場景，RocketMQ做了些高階功能，從而業務方可以少做一些事情。

關於這些特定功能，以及沒有這些特定功能的話，業務方如何自己解決。後續會在“RocketMQ”原始碼序列中，一一詳細闡述。