rabbitMq、rocketMq、kafaka適用場景對比
架構方面：
可靠性：
Kafaka是正常的mq架構，包括provider broker consumer。kafaka有消息確認機制ack
rabbitMq 中的broker由exchange、binder queue三部分組成，其中exchange和binding組成了消息的路由鍵；客戶端Producer通過連接channel和server進行通信，Consumer從queue獲取消息進行消費，rabbit有消息確認機制
RocketMQ支持異步/同步刷盤;異步/同步Replication；
Kafka使用異步刷盤方式，異步Replication。
結論：RocketMQ所支持的同步方式提升了數據的可靠性。
吞吐量方面：
Kafaka采用zero-copy方式，即數據存儲和獲取是本地磁盤順序批量操作，具有O（1）復雜度，數據處理效率很高
RabbitMq在吞吐量方面不如kafaka，RabbitMq支持對消息可靠的傳遞，支持事務，不支持批量的操作。
Kafka單機寫入 TPS 號稱在百萬條/秒；
RocketMQ 大約在10萬條/秒。
結論：追求性能的話，Kafka單機性能更高。
可用性方面
Kafaka的broker采用主備模式，所以可用性很高
RabbitMq支持miror queue，主queue失效，minor queue生效
集群負載方面
Kafaka使用zookeeper實現負載均衡，zookeeper管理集群中的broker sonsumer，通過zookeeper的協調機制，producer會記錄topic對應的broker，對broker進行輪詢或者隨機訪問broker，實現負載均衡
RabbitMq需要單獨自定義負載均衡
消息准確性方面
kafaka支持事務，對消息的重復、丟失、錯誤沒有嚴格要求，可以通過配置參數實現；
rabbitMq采用AMQP協議，AMQP協議更多用在企業系統內，對數據一致性、穩定性和可靠性要求很高的場景
rabbitMq,rocketMq對比
rabbitmq整體更穩定，延遲更小
rabbitMq社區更活躍
rabbitmq管理界面更好
rabbitmq吞吐量為萬級別，少一個量級
Rocketmq和Kafka區別
（1） 適用場景
Kafka適合日志處理；
RocketMQ適合業務處理。
結論：平手，根據具體業務定奪。
（2） 性能
Kafka單機寫入 TPS 號稱在百萬條/秒；
RocketMQ 大約在10萬條/秒。
結論：追求性能的話，Kafka單機性能更高。
（3） 可靠性
RocketMQ支持異步/同步刷盤;異步/同步Replication；
Kafka使用異步刷盤方式，異步Replication。
結論：RocketMQ所支持的同步方式提升了數據的可靠性。
（4） 實時性
均支持pull長輪詢，RocketMQ消息實時性更好
結論：RocketMQ 勝出。
（5） 支持的隊列數
Kafka單機超過64個隊列/分區，消息發送性能降低嚴重；
RocketMQ 單機支持最高5萬個隊列，性能穩定
結論：長遠來看，RocketMQ 勝出，這也是適合業務處理的原因之一
（6） 消息順序性
Kafka 某些配置下，支持消息順序，但是一台Broker宕機后，就會產生消息亂序；
RocketMQ支持嚴格的消息順序，在順序消息場景下，一台Broker宕機后，
發送消息會失敗，但是不會亂序；
結論：RocketMQ 勝出
（7）消費失敗重試機制
Kafka消費失敗支持重試，KafkaProducer通過設定參數retries
RocketMQ消費失敗支持定時重試，每次重試間隔時間順延。
（8）定時/延時消息
Kafka不支持定時消息；可以使用DelayQueue實現。
RocketMQ支持定時消息
（9）分布式事務消息
Kafka不支持分布式事務消息；
阿里雲ONS支持分布式定時消息，未來開源版本的RocketMQ也有計划支持分布式事務消息
（10）消息查詢機制
Kafka不支持消息查詢
RocketMQ支持根據Message Id查詢消息，也支持根據消息內容查詢消息
（11）消息回溯
Kafka理論上可以按照Offset來回溯消息
RocketMQ支持按照時間來回溯消息，精度毫秒，例如從一天之前的某時某分某秒開始重新消費消息
3. 為什么阿里會自研RocketMQ？
（1）Kafka的業務應用場景主要定位於日志傳輸；對於復雜業務支持不夠
（2）阿里很多業務場景對數據可靠性、數據實時性、消息隊列的個數等方面的要求很高。
kafka針對海量數據，但是對數據的正確度要求不是十分嚴格。而阿里巴巴中用於交易相關的事情較多，對數據的正確性要求極高，Kafka不合適
（3）當業務成長到一定規模，采用開源方案的技術成本會變高.
開源方案無法滿足業務的需要；舊版本、自開發代碼與新版本的兼容都可能是問題；運維角度，Kafka使用 scala 編寫，而阿里是java系。Kafka 的后續維護是個問題。
（4）阿里在團隊、成本、資源投入等方面約束性條件幾乎沒有.
綜上，阿里選擇自己開發RocketMQ更多是業務的驅動，當業務更多的需要以下功能的支持時，kafka 不能滿足或者 ActiveMQ 等其他消息中間件不能滿足，財大氣粗能力又強業務還復雜，所以就自己開發了。
4. 其他
另外認為kafka是用於日志傳輸，所以不適合系統的業務事件是個更大的誤區，Kafka本身在最早實現時的確是為了傳輸日志，但后來經過多年發展，其適用范圍早不限於日志，並且很多采取Kafka的公司並非用它來處理日志，kafka背后的 Confluence公司提供了很多基於kafka來簡化系統實現的例子。