redis和kafka的區(qū)別有哪些

這篇文章給大家分享的是有關(guān)redis和kafka的區(qū)別有哪些的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考。一起跟隨小編過來看看吧。

 Kafka與Redis PUB/SUB之間較大的區(qū)別在于Kafka是一個完整的系統(tǒng)，而Redis PUB/SUB只是一個套件(utility)——沒有冒犯Redis的意思，畢竟它的主要功能并不是PUB/SUB。

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

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

Redis，它首先是一個內(nèi)存數(shù)據(jù)庫，其提供的PUB/SUB功能把消息保存在內(nèi)存中(基于channel)，因此如果你的消息的持久性需求并不高且后端應(yīng)用的消費能力超強的話，使用Redis PUB/SUB是比較合適的使用場景。比如官網(wǎng)說提供的一個網(wǎng)絡(luò)聊天室的例子：模擬IRC，因為channel就是IRC中的服務(wù)器。用戶發(fā)起連接，發(fā)布消息到channel，接收其他用戶的消息。這些對于持久性的要求并不高，使用Redis PUB/SUB來做足矣。

而Kafka是一個完整的系統(tǒng)，它提供了一個高吞吐量、分布式的提交日志(由于提供了Kafka Connect和Kafka Streams，目前Kafka官網(wǎng)已經(jīng)將自己修正為一個分布式的流式處理平臺，這里也可以看出Kafka的野心：-)。除了p2p的消息隊列，它當(dāng)然提供PUB/SUB方式的消息模型。而且，Kafka默認(rèn)提供了消息的持久化，確保消息的不丟失性(至少是大部分情況下)。另外，由于消費元數(shù)據(jù)是保存在consumer端的，所以對于消費而言consumer被賦予極大的自由度。consumer可以順序地消費消息，也可以重新消費之前處理過的消息。這些都是Redis PUB/SUB無法做到的。

Redis PUB/SUB使用場景：

1. 消息持久性需求不高
2. 吞吐量要求不高
3. 可以忍受數(shù)據(jù)丟失
4. 數(shù)據(jù)量不大

Kafka使用場景：

上面以外的其他場景：）
1. 高可靠性
2. 高吞吐量
3. 持久性高
4. 多樣化的消費處理模型

感謝各位的閱讀！關(guān)于redis和kafka的區(qū)別有哪些就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！