概述

    在網上看到一篇主要講清楚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

    3、rocketMQ不具備選舉，Master/Slave的角色也是固定的（叢集中有寫磁碟和記憶體）。當一個Master掛了之後，你可以寫到其他Master上，但不能讓一個Slave切換成Master。那麼rocketMq是如何實現高可用的呢，其實很簡單，rocketMq的所有broker節點的角色都是一樣，上面分配的topic和對應的queue的數量也是一樣的（映象同步

    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操作，但是多個檔案之間必然會導致磁碟的尋道。