在應用場景方面
RabbitMQ
RabbitMQ遵循AMQP協議，由內在高並發的erlanng語言開發，用在實時的對可靠性要求比較高的消息傳遞上，適合企業級的消息發送訂閱，也是比較受到大家歡迎的。
kafka
kafka是Linkedin於2010年12月份開源的消息發布訂閱系統,它主要用於處理活躍的流式數據,大數據量的數據處理上。常用日志采集，數據采集上。
ActiveMQ
- 異步調用
- 一對多通信
- 做多個系統的集成，同構、異構
- 作為RPC的替代
- 多個應用相互解耦
- 作為事件驅動架構的幕后支撐
- 為了提高系統的可伸縮性
在架構模型方面，
RabbitMQ
RabbitMQ遵循AMQP協議，RabbitMQ的broker由Exchange,Binding,queue組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer通過連接channel和server進行通信，Consumer從queue獲取消息進行消費（長連接，queue有消息會推送到consumer端，consumer循環從輸入流讀取數據）。rabbitMQ以broker為中心；有消息的確認機制。
kafka
kafka遵從一般的MQ結構，producer，broker，consumer，以consumer為中心，消息的消費信息保存的客戶端consumer上，consumer根據消費的點，從broker上批量pull數據；無消息確認機制。
在吞吐量
kafka
kafka具有高的吞吐量，內部采用消息的批量處理，zero-copy機制，數據的存儲和獲取是本地磁盤順序批量操作，具有O(1)的復雜度，消息處理的效率很高。
rabbitMQ
rabbitMQ在吞吐量方面稍遜於kafka，他們的出發點不一樣，rabbitMQ支持對消息的可靠的傳遞，支持事務，不支持批量的操作；基於存儲的可靠性的要求存儲可以采用內存或者硬盤。
在可用性方面，
rabbitMQ
rabbitMQ支持miror的queue，主queue失效，miror queue接管。
kafka
kafka的broker支持主備模式。
在集群負載均衡方面，
kafka
kafka采用zookeeper對集群中的broker、consumer進行管理，可以注冊topic到zookeeper上；通過zookeeper的協調機制，producer保存對應topic的broker信息，可以隨機或者輪詢發送到broker上；並且producer可以基於語義指定分片，消息發送到broker的某分片上。
rabbitMQ
rabbitMQ的負載均衡需要單獨的loadbalancer進行支持。
Redis
是一個Key-Value的NoSQL數據庫，開發維護很活躍，雖然它是一個Key-Value數據庫存儲系統，但它本身支持MQ功能，所以完全可以當做一個輕量級的隊列服務來使用。對於RabbitMQ和Redis的入隊和出隊操作，各執行100萬次，每10萬次記錄一次執行時間。測試數據分為128Bytes、512Bytes、1K和10K四個不同大小的數據。實驗表明：入隊時，當數據比較小時Redis的性能要高於RabbitMQ，而如果數據大小超過了10K，Redis則慢的無法忍受；出隊時，無論數據大小，Redis都表現出非常好的性能，而RabbitMQ的出隊性能則遠低於Redis。
轉載自：https://www.zhihu.com/question/353858758/answer/941238205