Redis是一個高性能的key-value數據庫，它的出現很大程度補償了memcached這類key-value存儲的不足。雖然它是一個數據庫系統，但本身支持MQ功能，完全可以當做一個輕量級的隊列服務器使用。

不過，Redis只是提供一個高性能的、原子操作內存鍵值隊，具有高速訪問能力，雖可用做消息隊列的存儲，但是不具備消息隊列的任何功能和邏輯，要作做為消息隊列來實現的話，功能和邏輯要通過上層應用自己實現。

Redis從2.0版本開始支持發布/訂閱指令，發布者調用redis的publish方法往特定的channel發送消息，訂閱者在初始化的時候要訂閱到該channel，一旦有消息就會立即接收。

Redis 消息推送（基于分布式 pub/sub）多用于實時性較高的消息推送，并不保證可靠。redis-pub/sub斷電就清空，而使用redis-list作為消息推送雖然有持久化，但是也并非完全可靠不會丟。其他的mq和kafka保證可靠但有一些延遲（非實時系統沒有保證延遲）。
　　另外一點，redis 發布訂閱除了表示不同的 topic 外，并不支持分組。但kafka是支持分組的，比如kafka中發布一個東西，多個訂閱者可以分組，同一個組里只有一個訂閱者會收到該消息，而這個可以用作負載均衡。

Redis發布訂閱與rabbitmq的區別

可靠性

redis ：沒有相應的機制保證消息的可靠消費，如果發布者發布一條消息，而沒有對應的訂閱者的話，這條消息將丟失，不會存在內存中；

rabbitmq：具有消息消費確認機制，如果發布一條消息，還沒有消費者消費該隊列，那么這條消息將一直存放在隊列中，直到有消費者消費了該條消息，以此可以保證消息的可靠消費。

實時性

redis:實時性高，redis作為高效的緩存服務器，所有數據都存在內存中，所以它具有更高的實時性

消費者負載均衡：

rabbitmq隊列可以被多個消費者同時監控消費，但是每一條消息只能被消費一次，由于rabbitmq的消費確認機制，因此它能夠根據消費者的消費能力而調整它的負載；

redis發布訂閱模式，一個隊列可以被多個消費者同時訂閱，當有消息到達時，會將該消息依次發送給每個訂閱者，她是一種消息的廣播形式，redis本身不做消費者的負載均衡，因此消費效率存在瓶頸；

持久性

redis：redis的持久化是針對于整個redis緩存的內容，它有RDB和AOF兩種持久化方式（redis持久化方式，后續更新），可以將整個redis實例持久化到磁盤，以此來做數據備份，防止異常情況下導致數據丟失。

rabbitmq：隊列，每條消息都可以選擇性持久化，持久化粒度更小，更靈活；

隊列監控

rabbitmq實現了后臺監控平臺，可以在該平臺上看到所有創建的隊列的詳細情況，良好的后臺管理平臺可以方面我們更好的使用；

redis沒有所謂的監控平臺。

性能

性能上，對于RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高于RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。

總結

redis： 輕量級，低延遲，高并發，低可靠性；

rabbitmq：重量級，高可靠，異步，不保證實時；

rabbitmq是一個專門的AMQP協議隊列，他的優勢就在于提供可靠的隊列服務，并且可做到異步，而redis主要是用于緩存的，redis的發布訂閱模塊，可用于實現及時性，且可靠性低的功能。

Redis發布訂閱與ActiveMQ的比較
　　1. ActiveMQ支持多種消息協議，包括AMQP，MQTT，Stomp等，并且支持JMS規范，但Redis沒有提供對這些協議的支持；

2. ActiveMQ提供持久化功能，但Redis無法對消息持久化存儲，一旦消息被發送，如果沒有訂閱者接收，那么消息就會丟失；

3. ActiveMQ提供了消息傳輸保障，當客戶端連接超時或事務回滾等情況發生時，消息會被重新發送給客戶端，Redis沒有提供消息傳輸保障。

總之，ActiveMQ所提供的功能遠比Redis發布訂閱要復雜，畢竟Redis不是專門做發布訂閱的。但是如果系統中已經有了Redis，并且只需要基本的發布訂閱功能，可以考慮使用Redis的發布訂閱機制以滿足需求。

總結

以上是生活随笔為你收集整理的Redis 与 MQ 的区别的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。