一、Kafka、RabbitMQ、Redis消息中間件對比
在分布式系統中、消息中間件常用於系統間的數據交換,
按照實際業務需求場景以及運維成本，可以選擇適合自己的產品.
二、相關概念介紹
-
Kafka
1.基於Pull的模式來處理消息消費
2.追求高吞吐量
3.一開始的目的就是日志收集和傳輸
4.0.8版本開始支持復制，不支持事務，對消息的重復、丟失、錯誤沒有嚴格要求、適合產生大量數據的互聯網服務的數據收集業務. -
RabbitMQ
RabbitMQ是使用Erlang語言開發的開源消息隊列系統，基於AMQP協議來實現.
AMQP的主要特征
1.面向消息、隊列、路由（包括點對點和發布/訂閱）、可靠性、安全。
2.AMQP協議更多用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。
主要應用於如： dubbo框架（zookeeper用於注冊中心）、spring cloud等 -
Redis
Redis是一個基於Key-Value對的NoSQL數據庫，開發維護很活躍.
雖然他是一個Key-value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用
三、特性對比
1.在應用場景方面
RabbitMQ,遵從AMQP協議，由內在高並發的erlang語言開發，用在實時的對可靠性要求比較高的消息傳遞上.
Kafka是Linkedin於2010年12月份開源的消息訂閱系統，它主要用於處理活式的流式數據，大數據量的數據處理上.
2.在架構模型上
RabbitMQ遵循AMQP協議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer通過連接channel和server進行通信，Consumer從queue獲取消息進行消費（長連接，queue有消息會推送到consumer端，consumer循環從輸入流讀取數據）。rabbitMQ以broker為中心；有消息的確認機制。
kafka遵從一般的MQ結構，producer，broker，consumer，以consumer為中心，消息的消費信息保存的客戶端consumer上，consumer根據消費的點，從broker上批量pull數據；無消息確認機制。
3.在吞吐量方面
kafka具有高的吞吐量，內部采用消息的批量處理，zero-copy機制，數據的存儲和獲取是本地磁盤順序批量操作，具有O(1)的復雜度，消息處理的效率很高。
rabbitMQ在吞吐量方面稍遜於kafka，他們的出發點不一樣，rabbitMQ支持對消息的可靠的傳遞，支持事務，不支持批量的操作；基於存儲的可靠性的要求存儲可以采用內存或者硬盤。
4.在可用性方面
RabbitMQ支持miror的queue，主queue失效，miror queue接管
kafka的broker支持主備模式
5.在集群負載均衡方面
kafka采用zookeeper對集群中的broker、consumer進行管理，可以注冊topic到zookeeper上；通過zookeeper的協調機制，producer保存對應topic的broker信息，可以隨機或者輪詢發送到broker上；並且producer可以基於語義指定分片，消息發送到broker的某分片上。
RabbitMQ的負載均衡需要單獨的loadbalancer進行支持.
四、應用場景
rabbitmq比kafka可靠，kafka更適合IO高吞吐的處理，比如ELK日志收集
Kafka和RabbitMq一樣是通用意圖消息代理，他們都是以分布式部署為目的。但是他們對消息語義模型的定義的假設是非常不同的。
-
以下場景你比較適合使用Kafka。你有大量的事件(10萬以上/秒)、你需要以分區的，順序的，至少傳遞成功一次到混雜了在線和打包消費的消費者、你希望能重讀消息、你能接受目前是有限的節點級別高可用或則說你並不介意通過論壇/IRC工具得到還在幼兒階段的軟件的支持。
-
以下場景你比較適合使用RabbitMQ。你有較少的事件（2萬以上/秒）並且需要通過復雜的路由邏輯去找到消費者、你希望消息傳遞是可靠的、你並不關心消息傳遞的順序、你需要現在就支持集群-節點級別的高可用或則說你需要7*24小時的付費支持（當然也可以通過論壇/IRC工具）
-
redis 消息推送（基於分布式 pub/sub）多用於實時性較高的消息推送，並不保證可靠
redis 消息推送（基於分布式 pub/sub）多用於實時性較高的消息推送，並不保證可靠。其他的mq和kafka保證可靠但有一些延遲（非實時系統沒有保證延遲）。redis-pub/sub斷電就清空，而使用redis-list作為消息推送雖然有持久化，也並非完全可靠不會丟。
- redis是內存數據庫！redis他爹做了disque，你要不要試試。mq一般都采用訂閱～發布模型，如果你考慮性能，主要關注點就放在消費模型是pull還是push。影響最大的，應該是存儲結構。kafka的性能要在topic數量小於64的時候，才能發揮威力。partition決定的。極限情況下丟消息，例如：主寫入消息后，主機器宕機，並硬盤損壞