kafka是apache開源的消息隊列頂級項目之一，在大數據場景下使用較多，由linkedin開源，目前社區活躍，全球較多組織開始使用kafka來進行數據交換
RabbitMQ是流行的開源消息隊列系統，用erlang語言開發。RabbitMQ是AMQP（高級消息隊列協議）的標準實現。
| 對比項 | kafka | rabbitmq |
|---|---|---|
| 開發語言 | scala,Java | erlang |
| 是否支持多租戶 | 2.x.x支持多租戶 | 支持多租戶 |
| 是否支持topic優先級 | 不支持 | 支持 |
| 是否支持消息全局有序 | 不支持 | 支持 |
| 是否支持消息分區有序 | 支持 | 支持 |
| 是否內置監控 | 無內置監控 | 內置監控 |
| 是否支持多個生產者 | 一個topic支持多個生產者 | |
| 是否支持多個消費者 | 一個topic支持多個消費者 | |
| 是否支持一個分區多個消費者 | 不支持 | 不支持 |
| 是否支持JMX | 支持 | 不支持(非java語言編寫) |
| 是否支持加密 | 支持 | 支持 |
| 消息隊列協議支持 | 僅支持自定義協議 | 支持AMQP、MQTT、STOMP協議 |
| 客戶端語言支持 | 支持多語言客戶端 | 支持多語言客戶端 |
| 是否支持消息追蹤 | 不支持消息追蹤 | 支持消息追蹤 |
| 是否支持消費者推模式 | 不支持消費者推模式 | 支持消費者推模式 |
| 是否支持消費者拉模式 | 支持消費者拉模式 | 支持消費者拉模式 |
| 是否支持廣播消息 | 支持廣播消息 | 支持廣播消息 |
| 是否支持消息回溯 | 支持消息回溯，因爲消息持久化，消息被消費後會記錄offset和timstamp | 不支持，消息確認被消費後，會被刪除 |
| 是否支持消息數據持久化 | 支持消息數據持久 | 支持消息數據持久 |
| 是否支持消息堆積 | 支持消息堆積，並批量持久化到磁盤 | 支持閾值內的消息對接，無法支持較大的消息堆積 |
| 是否支持流量控制 | 支持控制用戶和客戶端流量 | 支持生產者的流量控制 |
| 是否支持事務性消息 | 支持 | 不支持 |
| 元數據管理 | 通過zookeeper進行管理 | 支持消息數據持久 |
| 默認服務端口 | 9200 | 5672 |
| 默認監控端口 | kafka web console 9000;kafka manager 9000; | 15672 |
| 網絡開銷 | 相對較小 | 相對較大 |
| 內存消耗 | 相對較小 | 相對較大 |
| cpu消耗 | 相對較大 | 相對較小 |
在實際生產應用中，通常會使用kafka作爲消息傳輸的數據管道，rabbitmq作爲交易數據作爲數據傳輸管道，主要的取捨因素則是是否存在丟數據的可能；rabbitmq在金融場景中經常使用，具有較高的嚴謹性，數據丟失的可能性更小，同事具備更高的實時性；而kafka優勢主要體現在吞吐量上，雖然可以通過策略實現數據不丟失，但從嚴謹性角度來講，大不如rabbitmq；而且由於kafka保證每條消息最少送達一次，有較小的概率會出現數據重複發送的情況；
1.kafka
名詞 解釋
Producer
消息的生成者
Consumer
消息的消費者
ConsumerGroup
消費者組，可以並行消費Topic中的partition的消息
Broker
緩存代理，Kafka集羣中的一臺或多臺服務器統稱broker.
Topic
Kafka處理資源的消息源(feeds of messages)的不同分類
Partition
Topic物理上的分組，一個topic可以分爲多個partion,每個partion是一個有序的隊列。partion中每條消息都會被分 配一個 有序的Id(offset)
Message
消息，是通信的基本單位，每個producer可以向一個topic（主題）發佈一些消息
Producers
消息和數據生成者，向Kafka的一個topic發佈消息的 過程叫做producers
Consumers
消息和數據的消費者，訂閱topic並處理其發佈的消費過程叫做consumers
在 Kafka 集羣中有 3 個分區，每個分區有 3 個副本，正好均勻地分佈在 3個 broker 上，灰色陰影的代表 leader 副本，非灰色陰影的代表 follower 副本，虛線表示 follower 副本從 leader 副本上拉取消息。當生產者寫入消息的時候都寫入 leader 副本，對於圖 8-23 中的 情形，每個 broker 都有消息從生產者流入;當消費者讀取消息的時候也是從 leader 副本中讀取 的，對於圖 8-23 中的情形，每個 broker 都有消息流出到消費者。
我們很明顯地可以看出，每個 broker 上的讀寫負載都是一樣的，這就說明 Kafka 可以通過 主寫主讀實現主寫從讀實現不了的負載均衡。上圖展示是一種理想的部署情況，有以下幾種 情況(包含但不僅限於)會造成一定程度上的負載不均衡:
(1)broker 端的分區分配不均。當創建主題的時候可能會出現某些 broker 分配到的分區數 多而其他 broker 分配到的分區數少，那麼自然而然地分配到的 leader 副本也就不均。
(2)生產者寫入消息不均。生產者可能只對某些 broker 中的 leader 副本進行大量的寫入操 作，而對其他 broker 中的 leader 副本不聞不問。
(3)消費者消費消息不均。消費者可能只對某些 broker 中的 leader 副本進行大量的拉取操 作，而對其他 broker 中的 leader 副本不聞不問。
(4)leader 副本的切換不均。在實際應用中可能會由於 broker 宕機而造成主從副本的切換， 或者分區副本的重分配等，這些動作都有可能造成各個 broker 中 leader 副本的分配不均。
對此，我們可以做一些防範措施。針對第一種情況，在主題創建的時候儘可能使分區分配 得均衡，好在 Kafka 中相應的分配算法也是在極力地追求這一目標，如果是開發人員自定義的 分配，則需要注意這方面的內容。對於第二和第三種情況，主寫從讀也無法解決。對於第四種 情況，Kafka 提供了優先副本的選舉來達到 leader 副本的均衡，與此同時，也可以配合相應的 監控、告警和運維平臺來實現均衡的優化。
在實際應用中，配合監控、告警、運維相結合的生態平臺，在絕大多數情況下 Kafka 都能 做到很大程度上的負載均衡。總的來說，Kafka 只支持主寫主讀有幾個優點:可以簡化代碼的 實現邏輯，減少出錯的可能;將負載粒度細化均攤，與主寫從讀相比，不僅負載效能更好，而 且對用戶可控;沒有延時的影響;在副本穩定的情況下，不會出現數據不一致的情況。爲此， Kafka 又何必再去實現對它而言毫無收益的主寫從讀的功能呢?這一切都得益於 Kafka 優秀的 架構設計，從某種意義上來說，主寫從讀是由於設計上的缺陷而形成的權宜之計。
offsets.topic.replication.factor=3
設置副本數量爲3,這樣當一臺消費者宕機時，其他消費者也可以進行消費
參考
https://www.cnblogs.com/haolujun/p/9632835.html