文章目錄
一、rocketMQ
二、Kafka
三、應用場景對比
四、RocketMQ和Kafka對比
1. 吞吐量對比
五、爲什麼阿里會自研RocketMQ？
六、分佈式消息隊列RocketMQ與Kafka架構上的巨大差異之1 -- 爲什麼RocketMQ要去除ZK依賴？
參考
一、rocketMQ
RocketMQ聯合創始人：選擇MQ時，要注意的有哪些？
參考URL: https://blog.csdn.net/weixin_34241036/article/details/86720807
RocketMQ 是一個來自阿里巴巴的分佈式消息中間件，於 2012 年開源，並在 2017 年正式成爲 Apache 頂級項目。據瞭解，包括阿里雲上的消息產品以及收購的子公司在內，阿里集團的消息產品全線都運行在 RocketMQ 之上，並且最近幾年的雙十一大促中，RocketMQ 都有搶眼表現。
隨着 2011 年 Kafka 從 Apache 頂級項目畢業，其自研存儲引擎帶來的海量消息堆積，高效的持久化特性走入我們的視野。但它特殊的日誌通道定位，是不能完全滿足阿里巴巴高頻的在線交易場景，爲此團隊設計並研發了新一代消息引擎 RocketMQ（內部叫 MetaQ），從最初的日誌傳輸領域到後來阿里集團全維度在線業務的支撐，RocketMQ 被廣泛用在交易，數據同步，緩存同步，IM 通訊，流計算，IoT 等場景。
說起數據表現，RocketMQ 在 2017 年雙十一當天的萬億級數據洪峯下，做到了 99.996% 的毫秒級響應，每秒支撐千萬級消息發佈，每條消息發佈平均響應時間不超過 3 毫秒，最大不超過 20 毫秒，而核心交易鏈路平均 Response Time 僅 3ms，在全球 Messaging 領域做到了領先水平。
RocketMQ 在低延遲，消息重試與追蹤，海量 Topic，多租戶，一致性多副本，數據可靠性等問題上進行了大量優化，對電商，金融領域的用戶來說，是一大利好。
二、Kafka
Kafka最初產生於LinkedIn，用於支撐LinkedIn的activity stream data 和operational metrics分析，被譽爲LinkedIn的“中樞神經系統”。2011年完成Apache開源 ，2012年10月完成孵化，2014年ApacheKafka中三位核心人員Jay Kreps，NehaNarkhede和 Jun Rao聯合成立Confluent公司，致力於爲企業提供實時數處理服務解決方案。
Apache Kafka 爲日誌處理而生，目前從社區來看，發力重點在流計算，IoT 等領域，和 Apache Spark Streaming，Apache Flink，Apache Storm 等一站式流計算平臺不同，它從 Apache Samza 這種輕量級方案汲取了養分，提供給用戶的是一個異步編程框架，用戶基於類庫編程，不需要考慮分發，部署，調度等一系列傳統流計算框架帶來的繁瑣工作。這種輕量級的解決方案在一些日誌處理，ETL 等場景更受大家歡迎。
三、應用場景對比
Kafka
Kafka是LinkedIn開源的分佈式發佈-訂閱消息系統，目前歸屬於Apache頂級項目。Kafka主要特點是基於Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用於日誌收集和傳輸。0.8版本開始支持複製，不支持事務，對消息的重複、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務。
總結: Kafka主要特點是基於Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用於日誌收集和傳輸，適合產生大量數據的互聯網服務的數據收集業務。
大型公司建議可以選用，如果有日誌採集功能，肯定是首選kafka了。
RocketMQ
RocketMQ是阿里開源的消息中間件，它是純Java開發，具有高吞吐量、高可用性、適合大規模分佈式系統應用的特點。RocketMQ思路起源於Kafka，但並不是Kafka的一個Copy，它對消息的可靠傳輸及事務性做了優化，目前在阿里集團被廣泛應用於交易、充值、流計算、消息推送、日誌流式處理、binglog分發等場景。
總結：天生爲金融互聯網領域而生，對於可靠性要求很高的場景，尤其是電商裏面的訂單扣款，以及業務削峯，在大量交易涌入時，後端可能無法及時處理的情況。
RoketMQ在穩定性上可能更值得信賴，這些業務場景在阿里雙11已經經歷了多次考驗，如果你的業務有上述併發場景，建議可以選擇RocketMQ。
應對一些高併發，高可靠以及高可用比較苛刻的場景，Apache RocketMQ 是一個不錯的選擇。最近留意到一個有趣的現象，國內一些中大型規模的公司普遍部署了兩套消息引擎，一套選擇 Apache RocketMQ 用在交易，數據分發等核心鏈路上，一套選擇 Apache Kafka 用在大數據等在線、離線分析鏈路上。毫無疑問，Kafka 目前在大數據生態建設這塊，確實具備一定的先發優勢。
目前，國內很多金融領域的領軍企業在構建自己的分佈式金融體系時，也都不約而同地選擇了 RocketMQ。
四、RocketMQ和Kafka對比
1. 吞吐量對比
Kafka的吞吐量最高，RocketMQ所有的消息均是順序寫文件（磁盤順序讀寫速度超過內存隨機讀寫）。
kafka在topic數量由64增長到256時，吞吐量下降了98%，rocmq只下降了16%。
原因：
這是因爲Kafka的每個Topic、每個分區都會對應一個物理文件。當Topic數量增加時，消息分散的落盤策略會導致磁盤IO競爭激烈成爲瓶頸。而RocketMQ所有的消息是保存在同一個物理文件中的，Topic和分區數對RocketMQ也只是邏輯概念上的劃分，所以Topic數的增加對RocketMQ的性能不會造成太大的影響。
Kafka
Kafka的吞吐量高達17.3w/s，不愧是高吞吐量消息中間件的行業老大。這主要取決於它的隊列模式保證了寫磁盤的過程是線性IO。此時broker磁盤IO已達瓶頸。
RocketMQ
RocketMQ也表現不俗，吞吐量在11.6w/s，磁盤IO %util已接近100%。RocketMQ的消息寫入內存後即返回ack，由單獨的線程專門做刷盤的操作，所有的消息均是順序寫文件。
五、爲什麼阿里會自研RocketMQ？
（1）Kafka的業務應用場景主要定位於日誌傳輸；對於複雜業務支持不夠
（2）阿里很多業務場景對數據可靠性、數據實時性、消息隊列的個數等方面的要求很高。
kafka針對海量數據，但是對數據的正確度要求不是十分嚴格。而阿里巴巴中用於交易相關的事情較多，對數據的正確性要求極高，Kafka不合適
（3）當業務成長到一定規模，採用開源方案的技術成本會變高.
開源方案無法滿足業務的需要；舊版本、自開發代碼與新版本的兼容都可能是問題；運維角度，Kafka使用 scala 編寫，而阿里是java系。Kafka 的後續維護是個問題。
（4）阿里在團隊、成本、資源投入等方面約束性條件幾乎沒有.
綜上，阿里選擇自己開發RocketMQ更多是業務的驅動，當業務更多的需要以下功能的支持時，kafka 不能滿足或者 ActiveMQ 等其他消息中間件不能滿足，財大氣粗能力又強業務還複雜，所以就自己開發了。
另外認爲kafka是用於日誌傳輸，所以不適合系統的業務事件是個更大的誤區，Kafka本身在最早實現時的確是爲了傳輸日誌，但後來經過多年發展，其適用範圍早不限於日誌，並且很多采取Kafka的公司並非用它來處理日誌，kafka背後的 Confluence公司提供了很多基於kafka來簡化系統實現的例子。
大家都在發展，功能的差異會很快抹平的。
RocketMQ 可以理解爲是Java版 的kafka。
六、分佈式消息隊列RocketMQ與Kafka架構上的巨大差異之1 – 爲什麼RocketMQ要去除ZK依賴？
分佈式消息隊列RocketMQ與Kafka架構上的巨大差異之1 – 爲什麼RocketMQ要去除ZK依賴？
參考URL: https://blog.csdn.net/gh670011677/article/details/75095460
在早期的RocketMQ版本中，是有依賴ZK的。而現在的版本中，是去掉了對ZK的依賴，轉而使用自己開發的NameSrv。
並且這個NameSrv是無狀態的，你可以隨意的部署多臺，其代碼也非常簡單，非常輕量。
那不禁要問了：ZooKeeper是業界用來管理集羣的一個非常常用的中間件，比如Kafka就是依賴的ZK。那爲什麼RocketMQ要自己造輪子，自己做集羣的管理呢？純粹就是再做一個Zookeeper嗎？
Master/Slave概念差異
Kafka: Master/Slave是個邏輯概念，1臺機器，同時具有Master角色和Slave角色。
RocketMQ: Master/Slave是個物理概念，1臺機器，只能是Master或者Slave。在集羣初始配置的時候，指定死的。其中Master的broker id = 0，Slave的broker id > 0。
Broker概念差異
Kafka: Broker是個物理概念，1個broker就對應1臺機器。
RocketMQ：Broker是個邏輯概念，1個broker = 1個master + 多個slave。所以纔有master broker, slave broker這樣的概念。
那這裏，master和slave是如何配對的呢？ 答案是通過broker name。具有同1個broker name的master和slave進行配對。
所以這裏可以看出：RokcetMQ和Kafka關於這2對概念的定義，剛好是反過來的！Kafka是先有Broker，然後產生出Master/Slave；RokcetMQ是先定義Master/Slave，然後組合出Broker。
答案：爲什麼可以去ZK?
在Kafka裏面，Maser/Slave是選舉出來的！！！RocketMQ不需要選舉！！！
而在RocketMQ中，不需要選舉，Master/Slave的角色也是固定的。當一個Master掛了之後，你可以寫到其他Master上，但不會說一個Slave切換成Master。
這種簡化，使得RocketMQ可以不依賴ZK就很好的管理Topic/queue和物理機器的映射關係了，也實現了高可用。
說到這，答案基本就知道了：RocketMQ不需要像Kafka那樣有很重的選舉邏輯，它把這個問題簡化了。剩下的就是topic/queue的路由信息，那用個簡單的NameServer就搞定了，很輕量，還無狀態，可靠性也能得到很好保證。
參考
RocketMQ聯合創始人：選擇MQ時，要注意的有哪些？
參考URL: https://blog.csdn.net/weixin_34241036/article/details/86720807
高併發架構系列：Kafka、RocketMQ、RabbitMQ的優劣勢比較
參考URL: https://blog.csdn.net/ChenRui_yz/article/details/86154132
消息中間件相關知識以及各種消息中間件的比較
參考URL: https://blog.csdn.net/Future_LL/article/details/86752329
RocketMQ 如何取代kafka，成爲滴滴出行的千億級消息引擎新選擇？
參考URL: https://www.jianshu.com/p/1efeb2e79926
Kafka、RabbitMQ、RocketMQ等消息中間件的介紹和對比
參考URL: https://www.jianshu.com/p/f2b6b4c439c5
技術選型：RocketMQ or Kafka
參考URL: https://blog.csdn.net/weixin_34104341/article/details/91441250
基於Kafka Connect的應用實踐——打造實時數據集成平臺
參考URL: https://cloud.tencent.com/developer/news/217133
————————————————
版權聲明：本文爲CSDN博主「西京刀客」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/inthat/article/details/100037860