概述
其實一直想寫一篇rocketMq和kafka在架構設計上的差別，但是一直有個問題沒搞明白所以遲遲沒動手，今天無意中聽人點播了一下似乎明白了這個問題，所以就有了這篇對比。
這篇博文主要講清楚kafka和rocketMq的兩個不同點，1、rocketMq的namesvr和kafka的zookeeper對比；2、kafka為什么比rocketMq有更大的吞吐量。如果能夠講清楚上面兩個問題我覺得就已經很滿足了。
最后，文章引入的參考文章里面有一些比較好的鏈接，有興趣的話可以好好看看，里面其實有些地方比我講解的更深入。
namesrv VS zk
1、我們可以對比下kafka和rocketMq在協調節點選擇上的差異，kafka通過zookeeper來進行協調，而rocketMq通過自身的namesrv進行協調。
2、kafka在具備選舉功能，在Kafka里面，Master/Slave的選舉，有2步：第1步，先通過ZK在所有機器中，選舉出一個KafkaController；第2步，再由這個Controller，決定每個partition的Master是誰，Slave是誰。因為有了選舉功能，所以kafka某個partition的master掛了，該partition對應的某個slave會升級為主對外提供服務。
3、rocketMQ不具備選舉，Master/Slave的角色也是固定的。當一個Master掛了之后，你可以寫到其他Master上，但不能讓一個Slave切換成Master。那么rocketMq是如何實現高可用的呢，其實很簡單，rocketMq的所有broker節點的角色都是一樣，上面分配的topic和對應的queue的數量也是一樣的，Mq只能保證當一個broker掛了，把原本寫到這個broker的請求遷移到其他broker上面，而並不是這個broker對應的slave升級為主。
4、rocketMq在協調節點的設計上顯得更加輕量，用了另外一種方式解決高可用的問題，思路也是可以借鑒的。
關於吞吐量
1、首先說明下面的幾張圖片來自於互聯網共享，也就是我后面參考文章里面的列出的文章。
2、kafka在消息存儲過程中會根據topic和partition的數量創建物理文件，也就是說我們創建一個topic並指定了3個partition，那么就會有3個物理文件目錄，也就說說partition的數量和對應的物理文件是一一對應的。
3、rocketMq在消息存儲方式就一個物流問題，也就說傳說中的commitLog，rocketMq的queue的數量其實是在consumeQueue里面體現的，在真正存儲消息的commitLog其實就只有一個物理文件。
4、kafka的多文件並發寫入 VS rocketMq的單文件寫入，性能差異kafka完勝可想而知。
5、kafka的大量文件存儲會導致一個問題，也就說在partition特別多的時候，磁盤的訪問會發生很大的瓶頸，畢竟單個文件看着是append操作，但是多個文件之間必然會導致磁盤的尋道。
參考文章
分布式消息隊列RocketMQ與Kafka架構上的巨大差異之1 -- 為什么RocketMQ要去除ZK依賴？
作者：晴天哥_374
鏈接：https://www.jianshu.com/p/c474ca9f9430
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。