Kafka，Mq，Redis作為消息隊列使用時的差異？

12-27

Kafka是作為新一代的消息系統，mq是比較成熟消息系統，而redis也可以發布訂閱了，那麼這三者有何異同？
自己查了查資料，了解了一下，其實，作為消息隊列來說，企業中選擇mq的還是多數，因為像Rabbit，Rocket等mq中間件都屬於很成熟的產品，性能一般但可靠性較強，而kafka原本設計的初衷是日誌統計分析，現在基於大數據的背景下也可以做運營數據的分析統計，而redis的主要場景是內存資料庫，作為消息隊列來說可靠性太差，而且速度太依賴網路IO，在伺服器本機上的速度較快，且容易出現數據堆積的問題，在比較輕量的場合下能夠適用。希望有更專業的人來總結總結。

redis 消息推送（基於分散式 pub/sub）多用於實時性較高的消息推送，並不保證可靠。
其他的mq和kafka保證可靠但有一些延遲（非實時系統沒有保證延遲）。redis-pub/sub斷電就清空，而使用redis-list作為消息推送雖然有持久化，但是又太弱智，也並非完全可靠不會丟。

另外一點，redis 發布訂閱除了表示不同的 topic 外，並不支持分組，比如kafka中發布一個東西，多個訂閱者可以分組，同一個組裡只有一個訂閱者會收到該消息，這樣可以用作負載均衡。

比如，kafka 中發布：topic = "發布帖子" data="文章1" 這個消息，後面有一百台伺服器每台伺服器都是一個訂閱者，都訂閱了這個 topic，但是他們可能分為三組，A組50台，用來真的做發布文章，A組50台里所有 subscriber 都訂閱了這個topic。

由於在同一組，這條消息（topic="發布帖子", data="文章1"）只會被A組裡面一台當前空閑的機器收到。而B組25台伺服器用於統計，C組25台伺服器用於存檔備份，每組只有一台會收到。

用不同的組來決定每條消息要抄送出多少分去，用同組內哪些訂閱者忙，哪些訂閱者空閑來決定消息會被分到哪台伺服器去處理，生產者消費者模型嘛。

redis完全沒有這類機制，這兩點是最大的區別。。。。。

贊同樓上幾位關於 Redis和Kafka ／ MQ 並不能apple to apple 比較的說法。

關於 @蘭竹同學有關Kafka的意見，有幾點補充說明：

1. Topic數量問題：在0.8.0版本以後，kafka flush就已經是非同步的了。所以文件數量要到非常大的時候才會成為瓶頸。舉個例子，在LinkedIn的時候我們的一個集群一般是128到256台機器，每個集群上可能有幾百甚至個topic，每一個topic從8個到2000多個partition不等，平均到一台機器上會有幾千個partition（機器的open file handler都是調到30000個），依然沒有看到IO造成的性能損失。

2. 極限情況下丟消息：如果在replication情況下，並且發送客戶端（producer）的ACK設置成 &> 1或者－1（即等待多個或者所有replica都存儲消息才回復）的情況下，宕機並硬碟損壞也不會發生丟信息的情況。斷電情況下，就是說你集群的一部分機器都掛了的時候，一般比較高端的集群都只會掛掉一整個rack但是不會是整個數據中心，如果replication的數據在不同rack上面的話依然不會丟包。在最新的0.10版本裡面用戶可以更輕鬆的配置這些rack-aware replication settings.

你的方向錯了，對！我就是說你錯了。

redis是內存資料庫！
redis是內存資料庫！
redis是內存資料庫！
redis他爹做了disque，你要不要試試。

mq一般都採用訂閱～發布模型，如果你考慮性能，主要關注點就放在消費模型是pull還是push。影響最大的，應該是存儲結構。

kafka的性能要在topic數量小於64的時候，才能發揮威力。partition決定的。極限情況下丟消息，例如：主寫入消息後，主機器宕機，並硬碟損壞。review代碼的時候發現的。

rabbit不知道，但是rocket的性能是（萬條每秒），並且能夠橫向無限擴展，單機topic數量在256時，性能損失較小。

rocket可以說是kafka的變種，是阿里在充分reviewkafka代碼後，開發的metaQ。在不斷更新，修補以後，阿里把metaQ3.0更名為rocket，並且rocket是java寫的易於維護。

另外就是rocket和kafka有類似無限堆積的能力。想想，斷電不丟消息，積壓兩億條消息毫無壓力，niubility

kafka和rocket性能根本不是你需要考慮的問題。

如果使用過程中，出現性能問題，先學怎麼用。肯定是你用錯了。

業界對於消息的傳遞有多種方案和產品，本文就比較有代表性的兩個MQ(rabbitMQ,kafka)進行闡述和做簡單的對比，
在應用場景方面，
RabbitMQ,遵循AMQP協議，由內在高並發的erlanng語言開發，用在實時的對可靠性要求比較高的消息傳遞上。
kafka是Linkedin於2010年12月份開源的消息發布訂閱系統,它主要用於處理活躍的流式數據,大數據量的數據處理上。
1)在架構模型方面，
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數據；無消息確認機制。
2)在吞吐量，
kafka具有高的吞吐量，內部採用消息的批量處理，zero-copy機制，數據的存儲和獲取是本地磁碟順序批量操作，具有O(1)的複雜度，消息處理的效率很高。
rabbitMQ在吞吐量方面稍遜於kafka，他們的出發點不一樣，rabbitMQ支持對消息的可靠的傳遞，支持事務，不支持批量的操作；基於存儲的可靠性的要求存儲可以採用內存或者硬碟。
3)在可用性方面，
rabbitMQ支持miror的queue，主queue失效，miror queue接管。
kafka的broker支持主備模式。
4)在集群負載均衡方面，
kafka採用zookeeper對集群中的broker、consumer進行管理，可以註冊topic到zookeeper上；通過zookeeper的協調機制，producer保存對應topic的broker信息，可以隨機或者輪詢發送到broker上；並且producer可以基於語義指定分片，消息發送到broker的某分片上。
rabbitMQ的負載均衡需要單獨的loadbalancer進行支持。
原文：RabbitMQ和kafka從幾個角度簡單的對比

只用過rabbitmq 和redis 。 rabbitmq 不用說，專門的消息隊列，可靠發布，可靠消費等等，但性能確實，之前項目用來配合做mysql binlog的分發，還是很可靠的。很適合企業級應用。 redis 的有序集合用來做隊列還是不錯的，用來實現做簡單的任務隊列，性能不錯，也有持久化（rdb/aof）但是發布、消費等的確認就要自己實現了。

不是卡夫卡做實時log分析，mq做伺服器消息通信，redis做緩存嗎。

開源軟體成熟度評測報告-分散式消息中間件

這是我們做的Kafka和RabbitMQ的完整評測報告，供參考

redis可以做隊列，但是redis的高潮在於緩存呀。隊列我還是用rabbitmq。kafka沒用過，沒有那麼大的並發量。

redis 可以做消息隊列
redis 可以做消息隊列
redis 可以做消息隊列

ELK官方推薦的broker就是用redis做的。

通過redis傳輸 · ELKstack 中文指南

為毛線消息隊列里要出現redis？要也是https://github.com/antirez/disque 啊

hypeledger fabric用的就是kafka

redis存儲之後，發消息給MQ,收到消息後，處理redis數據。這樣可行不？

redis不是消息隊列，redis不是消息隊列。