Redis:訂閱與發佈功能對比RabbitMQ消息隊列

【注：部分引用其餘博客內容，原做者不詳】

總結

服務	特性
Redis	輕量級，低延遲，高併發，低可靠性；
RabbitMQ	重量級，高可靠，異步，不保證明時；

應用

RabbitMQ是一個專門的AMQP協議隊列，他的優點就在於提供可靠的隊列服務，而且可作到異步，而redis主要是用於緩存的，Redis的發佈訂閱模塊，可用於實現及時性，且可靠性低的功能。

對比

iiiiiiiiiiiiiiiiiiii	Redis	RabbitMQ
可靠性	沒有相應的機制保證消息的可靠消費，若是發佈者發佈一條消息，而沒有對應的訂閱者的話，這條消息將丟失，不會存在內存中	具備消息消費確認機制，若是發佈一條消息，尚未消費者消費該隊列，那麼這條消息將一直存放在隊列中，直到有消費者消費了該條消息，以此能夠保證消息的可靠消費
實時性	Redis做爲高效的緩存服務器，全部數據都存在在服務器中，因此它具備更高的實時性
消費者負載均衡	發佈訂閱模式，一個隊列能夠被多個消費者同時訂閱，當有消息到達時，會將該消息依次發送給每一個訂閱者	隊列能夠被多個消費者同時監控消費，可是每一條消息只能被消費一次，因爲RabbitMQ的消費確認機制，所以它可以根據消費者的消費能力而調整它的負載
持久性	Redis的持久化是針對於整個redis緩存的內容，它有RDB和AOF兩種持久化方式（Redis持久化方式，後續更新），能夠將整個Redis實例持久化到磁盤，以此來作數據備份，防止異常狀況下致使數據丟失。	隊列消息均可以選擇性持久化，持久化粒度更小，更靈活；
隊列監控	Redis沒有所謂的監控平臺。	RabbitMQ實現了後臺監控平臺，能夠在該平臺上看到全部建立的隊列的詳細狀況，良好的後臺管理平臺能夠方面咱們更好的使用；

2019.06.27

在業務的實現過程當中，就算沒有大量的流量，解耦和異步化幾乎也是到處可用，此時MQ就顯得尤其重要。但與此同時MQ也是一個蠻重的組件，例如咱們若是用RabbitMQ就必須爲它搭建一個服務器，同時若是要考慮可用性，就要爲服務端創建一個集羣，並且在生產若是有問題也須要查找功能。在中小型業務的開發過程當中，可能業務的其餘整個實現都沒這個重。太重的組件服務會成倍增長工做量。 所幸的是，Redis提供的list數據結構也很是適合作消息隊列。