Kafka與Redis PUB/SUB之間較大的區別在於Kafka是一個完整的系統，而Redis PUB/SUB只是一個套件(utility)——沒有冒犯Redis的意思，畢竟它的主要功能並不是PUB/SUB。
redis 消息推送（基於分佈式 pub/sub）多用於實時性較高的消息推送，並不保證可靠。（推薦學習：Redis視頻教程）其他的mq和kafka保證可靠但有一些延遲（非實時系統沒有保證延遲）。redis-pub/sub斷電就清空，而使用redis-list作爲消息推送雖然有持久化，但是又太弱智，也並非完全可靠不會丟。
另外一點，redis 發佈訂閱除了表示不同的 topic 外，並不支持分組，比如kafka中發佈一個東西，多個訂閱者可以分組，同一個組裏只有一個訂閱者會收到該消息，這樣可以用作負載均衡。
Redis，它首先是一個內存數據庫，其提供的PUB/SUB功能把消息保存在內存中(基於channel)，因此如果你的消息的持久性需求並不高且後端應用的消費能力超強的話，使用Redis PUB/SUB是比較合適的使用場景。比如官網說提供的一個網絡聊天室的例子：模擬IRC，因爲channel就是IRC中的服務器。用戶發起連接，發佈消息到channel，接收其他用戶的消息。這些對於持久性的要求並不高，使用Redis PUB/SUB來做足矣。
而Kafka是一個完整的系統，它提供了一個高吞吐量、分佈式的提交日誌(由於提供了Kafka Connect和Kafka Streams，目前Kafka官網已經將自己修正爲一個分佈式的流式處理平臺，這裏也可以看出Kafka的野心：-)。除了p2p的消息隊列，它當然提供PUB/SUB方式的消息模型。而且，Kafka默認提供了消息的持久化，確保消息的不丟失性(至少是大部分情況下)。另外，由於消費元數據是保存在consumer端的，所以對於消費而言consumer被賦予極大的自由度。consumer可以順序地消費消息，也可以重新消費之前處理過的消息。這些都是Redis PUB/SUB無法做到的。
Redis PUB/SUB使用場景：
1. 消息持久性需求不高
2. 吞吐量要求不高
3. 可以忍受數據丟失
4. 數據量不大
Kafka使用場景：
上面以外的其他場景：
1. 高可靠性
2. 高吞吐量
3. 持久性高
4. 多樣化的消費處理模型