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. 多樣化的消費處理模型
更多Redis相關技術文章，請訪問Redis資料庫使用入門教學欄位學習！
以上是redis和kafka的區別的詳細內容。更多資訊請關注PHP中文網其他相關文章！
