只是一隻魚

Redis

看到問題的第一個反應是，MQ和Redis有啥可比性，再看了看題目【作為消息隊列使用時】，仔細想了想Redis何嘗不能作為消息隊列使用呢，就算是用數據庫實現也完全沒有問題。

Redis其實可以當做一個輕量級的隊列使用。Redis在數據量大的時候入隊較慢，Redis出隊則無論數據量大小性能都不錯。

只不過消息隊列中的很多功能都需要額外實現，平時我們還是把它用作內存數據庫吧。

Kafka和MQ

題目提出Kafka和MQ進行對比，這點我覺得很奇怪，因為我認為Kafka是分佈式消息中間件，有時候也會被稱作是一款MQ產品。

所以在我眼裡，MQ是一個總稱，Kafka也算MQ的一種，你要是說Kafka和RabbitMQ、RocketMQ相比有什麼異同，還能說得過去。

我的理解，如果理解有問題，請指正，當然我也知道Kafka是作為分佈式日誌系統發明出來的；並且MQ遵守了jms規範，kafka沒有遵循jms規範。

和其他MQ相比，Kafka的優勢：

• 可擴展：集群可以在線增加新的服務器
  

• 高性能：性能很高，吞吐量大
  
• 容錯性：每個Partition數據會複製到幾臺服務器上面，一臺掛了，可以用其他服務器上面的數據
  
  

缺點：

• 重複消息：小概率
  

• 消息亂序：partition之間的消息送達不保證有序

RabbitMQ

找一款MQ的產品RabbitMQ來進行一下對比，優點：

• 數據一致性
  

• 穩定

• 可靠性很高

缺點：

• 性能和吞吐量稍差
  

會點代碼的大叔

KAFKA

本人所在的公司使用kafa作為ETL數據通道，通過kafka配套的connect和schemaRegisty來方便快速實現異構數據源的相互轉換和存儲，通過connect插件生產和消費數據，通過schemaRegisty轉換異構數據（可以在幾乎所有你知道的數據源之間相互轉換），並且數據可以重複被消費（可以通過配置指定數據存儲時長）。kafka的開發團隊圍繞著kafka開發了一整套自成體系的生態圈（confluent platform）。

優點：

1. 可擴展。Kafka集群可以透明的擴展，增加新的服務器進集群。
2. 高性能。Kafka性能遠超過傳統的ActiveMQ、RabbitMQ等，Kafka支持Batch操作。
3. 容錯性。Kafka每個Partition數據會複製到幾臺服務器，當某個Broker失效時，Zookeeper將通知生產者和消費者從而使用其他的Broker。

缺點：

1. 重複消息。Kafka保證每條消息至少送達一次，雖然幾率很小，但一條消息可能被送達多次。
2. 消息亂序。Kafka某一個固定的Partition內部的消息是保證有序的，如果一個Topic有多個Partition，partition之間的消息送達不保證有序。
3. 複雜性。Kafka需要Zookeeper的支持，Topic一般需要人工創建，部署和維護比一般MQ成本更高。

MQ

消息隊列中間件還有很多種,列舉幾個:

零一數碼

Kafka作為新一代的消息系統，mq是比較成熟消息系統，而redis也可以發佈訂閱，那麼這三者有何異同？

RabbitMQ

是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。同時實現了一個經紀人(Broker)構架，這意味著消息在發送給客戶端時先在中排隊。對路由(Routing)，負載均衡(Load balance)或者數據持久化都有很好的支持。

Redis

是一個Key-Value的NoSQL數據庫，開發維護很活躍，雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低於Redis。

Kafka

Kafka是Apache下的一個子項目，是一個高性能跨語言分佈式Publish/Subscribe消息隊列系統，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；完全的分佈式系統，Broker、Producer、Consumer都原生自動支持分佈式，自動實現複雜均衡；支持Hadoop數據並行加載，對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的並行加載機制來統一了在線和離線的消息處理，這一點也是本課題所研究系統所看重的。Apache Kafka相對於ActiveMQ是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分佈式系統。

對比MQ與Kafka

1)在架構模型方面

RabbitMQ遵循AMQP協議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer通過連接channel和server進行通信，Consumer從queue獲取消息進行消費（長連接，queue有消息會推送到consumer端，consumer循環從輸入流讀取數據）。rabbitMQ以broker為中心；有消息的確認機制。

kafka遵從一般的MQ結構，producer，broker，consumer，以consumer為中心，消息的消費信息保存的客戶端consumer上，consumer根據消費的點，從broker上批量pull數據；無消息確認機制。

2)在吞吐量

kafka具有高的吞吐量，內部採用消息的批量處理，zero-copy機制，數據的存儲和獲取是本地磁盤順序批量操作，具有O(1)的複雜度，消息處理的效率很高。

rabbitMQ在吞吐量方面稍遜於kafka，他們的出發點不一樣，rabbitMQ支持對消息的可靠的傳遞，支持事務，不支持批量的操作；基於存儲的可靠性的要求存儲可以採用內存或者硬盤。

3)在可用性方面，

rabbitMQ支持miror的queue，主queue失效，miror queue接管。

Java高併發框架

補充一下使用場景：

Redis 消息隊列：高併發，輕量級，低延遲，吞吐量不大，對持久化要求不高的場景

Kafka消息隊列：高吞吐量，實時流式處理，持久化，高可用在至100k+/sec，多一次語義

Mq:輕量級消息，高可用在20k+/sec，快速響應，更好的事務控制，更復雜的路由支持，和更多開發語言的兼容支持。

小鳥攻城獅

RabbitMQ

是使用 Erlang 編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級，更適合於企業級的開發。同時實現了一個經紀人（Broker）構架，這意味著消息在發送給客戶端時先在中排隊。對路由（Routing），負載均衡（Load balance）或者數據持久化都有很好的支持。

Redis

是一個 Key-Value 的 NoSQL 數據庫，開發維護很活躍，雖然它是一個 Key-Value 數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對於 RabbitMQ 和 Redis 的入隊和出隊操作，各執行 100萬次，每 10 萬次記錄一次執行時間。測試數據分為 128Bytes、512Bytes、1K 和 10K 四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高於 RabbitMQ，而如果數據大小超過了 10K，Redis 則慢的無法忍受；出隊時，無論數據大小，Redis 都表現出非常好的性能，而RabbitMQ的出隊性能則遠低於Redis。

Kafka

Kafka 是 Apache 下的一個子項目，是一個高性能跨語言分佈式 Publish/Subscribe 消息隊列系統，而 Jafka 是在 Kafka 之上孵化而來的，即 Kafka 的一個升級版。具有以下特性：快速持久化，可以在 O(1) 的系統開銷下進行消息持久化；高吞吐，在一臺普通的服務器上既可以達到10W/s的吞吐速率；完全的分佈式系統，Broker、Producer、Consumer 都原生自動支持分佈式，自動實現複雜均衡；支持 Hadoop 數據並行加載，對於像 Hadoop 的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka 通過 Hadoop 的並行加載機制來統一了在線和離線的消息處理，這一點也是本課題所研究系統所看重的。Apache Kafka 相對於 ActiveMQ 是一個非常輕量級的消息系統，除了性能非常好之外，還是一個工作良好的分佈式系統。

對比 MQ 與 Kafka

• 在架構模型方面

RabbitMQ 遵循 AMQP協議，RabbitMQ 的 broker 由 Exchange,Binding,queue 組成，其中 exchange 和 binding 組成了消息的路由鍵；客戶端 Producer 通過連接channel 和 server 進行通信，Consumer 從 queue 獲取消息進行消費（長連接，queue 有消息會推送到 consumer 端，consumer 循環從輸入流讀取數據）。rabbitMQ 以 broker 為中心；有消息的確認機制。

kafka 遵從一般的 MQ 結構，producer，broker，consumer，以 consumer 為中心，消息的消費信息保存的客戶端 consumer上，consumer 根據消費的點，從 broker 上批量 pull 數據；無消息確認機制。

• 在吞吐量

kafka具有高的吞吐量，內部採用消息的批量處理，zero-copy 機制，數據的存儲和獲取是本地磁盤順序批量操作，具有 O(1) 的複雜度，消息處理的效率很高。

rabbitMQ 在吞吐量方面稍遜於 kafka，他們的出發點不一樣，rabbitMQ 支持對消息的可靠的傳遞，支持事務，不支持批量的操作；基於存儲的可靠性的要求存儲可以採用內存或者硬盤。

• 在可用性方面，

rabbitMQ 支持 miror 的 queue，主 queue 失效，miror queue 接管。

曲翎風

Kafka

kafka是個日誌處理緩衝組件，主要在大數據信息處理中使用。和傳統的消息隊列相比簡化了隊列結構和功能，以文件流形式處理存儲（持久化）消息（主要是日誌）。

日誌信息通常數據量巨大，處理組件一般會處理不過來，所以有了緩衝層kafka。kafka支持巨大的日誌吞吐量。為了防止數據丟失，其消息被消費後不會直接丟棄，要多存儲一段時間，等超過設置的時間閾值才會丟棄。這是mq和redis所不具備的。

主要特點如下:

巨型存儲量: 支持TB甚至PB級別數據。

高吞吐，高IO：一般配置的服務器就可實現單機每秒100K條以上的消息傳輸。

消息分區，分佈式消費：能保證消息順序傳輸。 支持離線數據處理（hadoop集群）和實時數據處理。

橫向擴展：支持在線水平擴展，以支持更大數據處理能力。

redis

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

MQ，消息隊列

我們以RabbitMQ為例來做介紹。它是用Erlang語言開發的開源消息隊列，支持多種協議包括AMQP，XMPP, SMTP, STOMP，適合於企業級的開發。

MQ支持Broker構架，消息發送給客戶端時需要在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。

其他更多消息隊列

還有ActiveMq，ZeroMq等，功能上大同小異。

有專門測試的結果表明，併發吞吐TPS比較，ZeroMq 最好，RabbitMq 次之， ActiveMq 最差。

更多信息，請關注蟲蟲，一起討論學習。

蟲蟲安全

分別來說一下：

kafka目前主要作為大數據的流式處理的隊列組件，作為大數據的組件，必然是可以處理海量的數據，並且必須具備高可用的特性，是一種分佈式的消息隊列，保存的數據既有內存中，也有硬盤中，硬盤中的數據默認保留7天。

redis作為目前大熱的內存nosql，是一種分佈式的內存k-v型數據庫，也可以作為消息隊列使用，是使用了redis的列表類型，並非專門的消息隊列，相比於kafka而言，無法處理海量的數據，但是讀取速度由於是內存讀取，速度相對較快。

mq作為傳統的消息隊列，主要應用於傳統項目，相對於前二者而言不具備分佈式高可用特性。

可按需求來使用。

關鍵字: Redis 隊列 科技