要做技術選型，那么必須對現今的各個消息中間件有個深入的理解才能做技術選型。否則別人問你，你為什么要用這個消息中間件，你說不出個所以然來，怎么做架構師呢？
截止到目前為止，現在業界流行的消息隊列中間件有：Redis、ActiveMQ、RabbitMQ、RocketMQ、Kafka。下面我們將逐個對他們進行分析介紹。
Redis
在我們印象中，Redis 是一個 key-value 緩存中間件，而不是一個消息隊列中間件。但事實上它本身支持 MQ 功能，所以完全可以當做一個輕量級的隊列服務來使用。對於 RabbitMQ 和 Redis 的入隊和出隊操作，各執行 100 萬次，每 10 萬次記錄一次執行時間。測試數據分為 128Bytes、512Bytes、1K 和 10K 四個不同大小的數據。
實驗表明：入隊時，當數據比較小時 Redis 的性能要高於 RabbitMQ，而如果數據大小超過了 10K，Redis 則慢的無法忍受；出隊時，無論數據大小，Redis 都表現出非常好的性能，而 RabbitMQ 的出隊性能則遠低於 Redis。
但在實際應用中，大家在考慮消息中間件的時候一般都不考慮 Redis。我想有兩個原因，一方面是數據大小超過 10K 速度很慢，另一個問題是 Redis 給人的印象就是做緩存的。基於上面這兩點原因，Redis 更適合用來做很小規模、業務簡單的消息隊列場景。 如果業務復雜、業務規模大，一般情況下 Redis 就會被排除。
ActiveMQ
ActiveMQ 是 Apache 下的一個子項目。 類似於 ZeroMQ，它能夠以代理人和點對點的技術實現隊列。同時類似於 RabbitMQ，它少量代碼就可以高效地實現高級應用場景。
RabbitMQ
RabbitMQ 是使用 Erlang 編寫的一個開源的消息隊列，本身支持很多的協議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合於企業級的開發。同時實現了 Broker 構架，這意味着消息在發送給客戶端時先在中心隊列排隊。對路由，負載均衡或者數據持久化都有很好的支持。
Kafka
Kafka 是 Apache 下的一個子項目，是一個高性能跨語言分布式發布 / 訂閱消息隊列系統。它具有以下特性：快速持久化，可以在 O(1) 的系統開銷下進行消息持久化；高吞吐，在一台普通的服務器上既可以達到 10W/s 的吞吐速率；完全的分布式系統，Broker、Producer、Consumer 都原生自動支持分布式，自動實現負載均衡；支持 Hadoop 數據並行加載，對於像 Hadoop 的一樣的日志數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。
RocketMQ
RocketMQ 是阿里巴巴開源的一個項目，目前已經納入 Apache 基金會。其是在 Kafka 的基礎上發展起來的，起因是隨着阿里巴巴業務的發展，他們發現 Kafka 對於具體業務場景的支持不完善，所以才有了 RocketMQ 的誕生。
與 Kafka 比起來，RocketMQ 很多方面都極其相似。唯一的不同是 RocketMQ 對於業務特性的支持更完善，所以更適用於業務場景。
下面的表格從各個方面對比了上面的幾個消息隊列：
從上面的表格我們可以看出幾個簡單的結論：
- 無論是在單機吞吐量還是可用性方面，ActiveMQ和RabbitMQ都差不多，而RocketMQ和Kafka差不多。
- 在功能特性方面，ActiveMQ、RabbitMQ、RocketMQ功能比較完善。Kafka功能性較弱。
基於以上的幾點幾輪，我們可以把消息隊列歸結為以下幾類：
- Redis
對於 Redis 來說，緩存才是主業，隊列功能只是一個附加功能。所以更加適合於業務簡單、規模小的業務場景。
- RabbitMQ、ActiveMQ
根據上面的對比，我們可以知道 RabbitMQ 和 ActiveMQ 的優點是功能豐富，缺點是單機性能和可用性稍弱。
對於中小型公司來說，它們的需求是：研發成本低、快速上手，不需要太高的性能。可以看到 RabbitMQ 和 ActiveMQ 就是為中小型公司量身定做的。
而在 RabbitMQ 和 ActiveMQ 這兩個消息中間件中，RabbitMQ 的更新頻率和社區更加活躍一些，所以可以優先選擇 RabbitMQ 作為中間件。
- RocketMQ、Kafka
對於 RocketMQ 和 Kafka 來說，雖然他們的單機吞吐量高、可用性也很高。但這意味着他們的技術也更加復雜，對於研發人員的要求也越高。
而對於大型互聯網公司，其對於吞吐量和可用性的要求更高，並且有許多定制化的需求。所以大型互聯網公司更加適合用 RocketMQ 和 Kafka。
而對於 RocketMQ 和 Kafka 這兩者來說，它們的對比也很明顯。RocketMQ 犧牲了一些性能，換來業務特性的支持。而 Kafka 則支持極致的吞吐量。所以在業務場景下使用 RocketMQ，而非業務場景則使用 Kafka。
| 框架 | 特點 | 業務場景 |
|---|---|---|
| redis | 功能簡單 | 簡單的業務場景、規模小 |
| RabbitMQ、ActiveMQ | 功能豐富、吞吐量和可用性適中 | 稍微復雜的業務場景、規模適中（中小公司） |
| RocketMQ | 功能豐富、定制化強、吞吐量和可用性高 | 復雜的業務場景、規模大（大型公司的業務場景） |
| Kafka | 吞吐量、可用性超高 | 規模超大的非業務場景（大型公司的非業務場景） |
總結
本文講了下面幾個要點：
- 業界流行框架的介紹
- 各大消息中間件的對比
看完之后，你應該能解答下面幾個問題：
- 我的系統要使用哪個消息隊列中間件？
下篇，我們聊聊使用消息隊列需要考慮的幾個問題。