一、RabbitMq
協議：AMQP
序列化：byte、json
實現語言：Elang
1、特點
（1）RabbitMQ 一個比較有特色的功能是支持非常靈活的路由配置，和其他消息隊列不同的是，它在生產者（Producer）和隊列（Queue）之間增加了一個 Exchange 模塊，你可以理解爲交換機。路由的規則也非常靈活，甚至你可以自己來實現路由規則
（2）RabbitMQ 的客戶端支持的編程語言大概是所有消息隊列中最多的，如果你的系統是用某種冷門語言開發的，那你多半可以找到對應的 RabbitMQ 客戶端。
2、缺點/問題
（1）RabbitMQ 對消息堆積的支持並不好，消息隊列是一個管道，大量的消息積壓是一種不正常的情況，應當儘量去避免。當大量消息積壓的時候，會導致 RabbitMQ 的性能急劇下降。
（2）第二個問題是，RabbitMQ 的性能是我們介紹的這幾個消息隊列中最差的，根據官方給出的測試數據綜合我們日常使用的經驗，依據硬件配置的不同，它大概每秒鐘可以處理幾萬到十幾萬條消息。
（3）RabbitMQ 使用的編程語言 Erlang，這個編程語言不僅是非常小衆的語言，更麻煩的是，這個語言的學習曲線非常陡峭。Elang學習成本高，所以如果你想基於 RabbitMQ 做一些擴展和二次開發什麼的，建議你慎重考慮一下可持續維護的問題。
二、RocketMq
消息協議：RocketMq協議
序列化方式：Json、Protobuf
實現語言：Java
1、特點
（1）RocketMQ 有着不錯的性能，穩定性和可靠性，具備一個現代的消息隊列應該有的幾乎全部功能和特性，並且它還在持續的成長中。
（2）RocketMQ 有非常活躍的中文社區，大多數問題你都可以找到中文的答案，也許會成爲你選擇它的一個原因。
（3）RocketMQ 使用 Java 語言開發，它的貢獻者大多數都是中國人，源代碼相對也比較容易讀懂，你很容易對 RocketMQ 進行擴展或者二次開發。
（4）非常強悍的性能，RocketMQ 對在線業務的響應時延做了很多的優化，大多數情況下可以做到毫秒級的響應，如果你的應用場景很在意響應時延，那應該選擇使用 RocketMQ。吞吐量上每秒鐘大概能處理幾十萬條消息。
2、缺點/問題
（1）RocketMQ 的一個劣勢是，作爲國產的消息隊列，相比國外的比較流行的同類產品，在國際上還沒有那麼流行，與周邊生態系統的集成和兼容程度要略遜一籌。但是有阿里這樣的巨頭背景，詳細很快也會有很大突破
三、Kafka
協議：自定義協議
序列化：byte、Avro、JSON、Thrift、ProtoBuf等
實現語言：Scala、Java
1、特點
（1）Kafka 與周邊生態系統的兼容性是最好的沒有之一，尤其在大數據和流計算領域，幾乎所有的相關開源軟件系統都會優先支持 Kafka。
（2）到超高的性能。Kafka 的性能，尤其是異步收發的性能，是三者中最好的，大約每秒鐘可以處理幾十萬到百萬條消息。開啓壓縮的情況下，甚至可以達到千萬級別
2、缺點/問題
（1）異步批量的設計帶來的問題是，它的同步收發消息的響應時延比較高，因爲當客戶端發送一條消息的時候，Kafka 並不會立即發送出去，而是要等一會兒攢一批再發送，在它的 Broker 中，很多地方都會使用這種“先攢一波再一起處理”的設計。當你的業務場景中，每秒鐘消息數量沒有那麼多的時候，Kafka 的時延反而會比較高。所以，Kafka 不太適合在線業務場景。
四、總結
1、如果消息隊列並不是你將要構建系統的主角之一，你對消息隊列功能和性能都沒有很高的要求，只需要一個開箱即用易於維護的產品，建議使用 RabbitMQ。
2、如果你的系統使用消息隊列主要場景是處理在線業務，比如在交易系統中用消息隊列傳遞訂單，那 RocketMQ 的低延遲和金融級的穩定性是你需要的。
3、如果你需要處理海量的消息，像收集日誌、監控信息或是前端的埋點這類數據，或是你的應用場景大量使用了大數據、流計算相關的開源產品，那Kafka 是最適合的