參考：

https://www.cnblogs.com/ynyhl/p/11320797.html

https://blog.csdn.net/weixin_34104341/article/details/91441250

https://blog.csdn.net/Cy_LightBule/article/details/88795437

https://blog.csdn.net/m0_38075425/article/details/81353738

kafka與Rocketmq的區別

淘寶內部的交易系統使用了淘寶自主研發的Notify訊息中介軟體，使用Mysql作為訊息儲存媒介，可完全水平擴容，為了進一步降低成本，我們認為儲存部分可以進一步優化，2011年初，Linkin開源了Kafka這個優秀的訊息中介軟體，淘寶中介軟體團隊在對Kafka做過充分Review之後，Kafka無限訊息堆積，高效的持久化速度吸引了我們，但是同時發現這個訊息系統主要定位於日誌傳輸，對於使用在淘寶交易、訂單、充值等場景下還有諸多特性不滿足，為此我們重新用Java語言編寫了RocketMQ，定位於非日誌的可靠訊息傳輸（日誌場景也OK），目前RocketMQ在阿里集團被廣泛應用在訂單，交易，充值，流計算，訊息推送，日誌流式處理，binglog分發等場景

資料可靠性

• RocketMQ支援非同步實時刷盤，同步刷盤，同步Replication，非同步Replication
• Kafka使用非同步刷盤方式，非同步Replication

總結：RocketMQ的同步刷盤在單機可靠性上比Kafka更高，不會因為作業系統Crash，導致資料丟失。 同時同步Replication也比Kafka非同步Replication更可靠，資料完全無單點。另外Kafka的Replication以topic為單位，支援主機宕機，備機自動切換，但是這裡有個問題，由於是非同步Replication，那麼切換後會有資料丟失，同時Leader如果重啟後，會與已經存在的Leader產生資料衝突。開源版本的RocketMQ不支援Master宕機，Slave自動切換為Master，

阿里雲版本的RocketMQ支援自動切換特性。

效能對比

• Kafka單機寫入TPS約在百萬條/秒，訊息大小10個位元組
• RocketMQ單機寫入TPS單例項約7萬條/秒，單機部署3個Broker，可以跑到最高12萬條/秒，訊息大小10個位元組

總結：Kafka的TPS跑到單機百萬，主要是由於Producer端將多個小訊息合併，批量發向Broker。

RocketMQ為什麼沒有這麼做？

1. Producer通常使用Java語言，快取過多訊息，GC是個很嚴重的問題
2. Producer呼叫傳送訊息介面，訊息未傳送到Broker，向業務返回成功，此時Producer宕機，會導致訊息丟失，業務出錯
3. Producer通常為分散式系統，且每臺機器都是多執行緒傳送，我們認為線上的系統單個Producer每秒產生的資料量有限，不可能上萬。
4. 快取的功能完全可以由上層業務完成。

單機支援的佇列數

• Kafka單機超過64個佇列/分割槽，Load會發生明顯的飆高現象，佇列越多，load越高，傳送訊息響應時間變長
• RocketMQ單機支援最高5萬個佇列，Load不會發生明顯變化

佇列多有什麼好處？

1. 單機可以建立更多Topic，因為每個Topic都是由一批佇列組成
2. Consumer的叢集規模和佇列數成正比，佇列越多，Consumer叢集可以越大

訊息投遞實時性

• Kafka使用短輪詢方式，實時性取決於輪詢間隔時間
• RocketMQ使用長輪詢，同Push方式實時性一致，訊息的投遞延時通常在幾個毫秒。

消費失敗重試

• Kafka消費失敗不支援重試
• RocketMQ消費失敗支援定時重試，每次重試間隔時間順延

總結：例如充值類應用，當前時刻呼叫運營商閘道器，充值失敗，可能是對方壓力過多，稍後在呼叫就會成功，如支付寶到銀行扣款也是類似需求。

這裡的重試需要可靠的重試，即失敗重試的訊息不因為Consumer宕機導致丟失。

嚴格的訊息順序

• Kafka支援訊息順序，但是一臺Broker宕機後，就會產生訊息亂序
• RocketMQ支援嚴格的訊息順序，在順序訊息場景下，一臺Broker宕機後，傳送訊息會失敗，但是不會亂序

Mysql Binlog分發需要嚴格的訊息順序

定時訊息

• Kafka不支援定時訊息
• RocketMQ支援兩類定時訊息
  • 開源版本RocketMQ僅支援定時Level
  • 阿里雲ONS支援定時Level，以及指定的毫秒級別的延時時間

分散式事務訊息

• Kafka不支援分散式事務訊息
• 阿里雲ONS支援分散式定時訊息，未來開源版本的RocketMQ也有計劃支援分散式事務訊息

訊息查詢

• Kafka不支援訊息查詢
• RocketMQ支援根據Message Id查詢訊息，也支援根據訊息內容查詢訊息（傳送訊息時指定一個Message Key，任意字串，例如指定為訂單Id）

總結：訊息查詢對於定位訊息丟失問題非常有幫助，例如某個訂單處理失敗，是訊息沒收到還是收到處理出錯了。

訊息回溯

• Kafka理論上可以按照Offset來回溯訊息
• RocketMQ支援按照時間來回溯訊息，精度毫秒，例如從一天之前的某時某分某秒開始重新消費訊息

總結：典型業務場景如consumer做訂單分析，但是由於程式邏輯或者依賴的系統發生故障等原因，導致今天消費的訊息全部無效，需要重新從昨天零點開始消費，那麼以時間為起點的訊息重放功能對於業務非常有幫助。

消費並行度

• Kafka的消費並行度依賴Topic配置的分割槽數，如分割槽數為10，那麼最多10臺機器來並行消費（每臺機器只能開啟一個執行緒），或者一臺機器消費（10個執行緒並行消費）。即消費並行度和分割槽數一致。

• RocketMQ消費並行度分兩種情況

  • 順序消費方式並行度同Kafka完全一致
  • 亂序方式並行度取決於Consumer的執行緒數，如Topic配置10個佇列，10臺機器消費，每臺機器100個執行緒，那麼並行度為1000。

訊息軌跡

• Kafka不支援訊息軌跡
• 阿里雲ONS支援訊息軌跡

開發語言友好性

• Kafka採用Scala編寫
• RocketMQ採用Java語言編寫

Broker端訊息過濾

• Kafka不支援Broker端的訊息過濾
• RocketMQ支援兩種Broker端訊息過濾方式
  • 根據Message Tag來過濾，相當於子topic概念
  • 向伺服器上傳一段Java程式碼，可以對訊息做任意形式的過濾，甚至可以做Message Body的過濾拆分。

訊息堆積能力

理論上Kafka要比RocketMQ的堆積能力更強，不過RocketMQ單機也可以支援億級的訊息堆積能力，我們認為這個堆積能力已經完全可以滿足業務需求。

開源社群活躍度

• Kafka社群更新較慢
• RocketMQ的github社群有250個個人、公司使用者登記了聯絡方式，QQ群超過1000人。

商業支援

• Kafka原開發團隊成立新公司，目前暫沒有相關產品看到
• RocketMQ在阿里雲上已經開放公測近半年，目前以雲服務形式免費供大家商用，並向用戶承諾99.99%的可靠性，同時徹底解決了使用者自己搭建MQ產品的運維複雜性問題

成熟度

• Kafka在日誌領域比較成熟
• RocketMQ在阿里集團內部有大量的應用在使用，每天都產生海量的訊息，並且順利支援了多次天貓雙十一海量訊息考驗，是資料削峰填谷的利器。

轉載：https://blog.csdn.net/damacheng/article/details/42846549

技術選型：RocketMQ or Kafka

當業務需要系統間呼叫解耦時，MQ 是一個很好的方案，目前選擇最多的當屬Kafka和阿里的RocketMQ, 兩種中介軟體都可以使用，都是備選方案，擺在面前，怎麼選擇？

1. 方法論-評估和選擇備選方案的方法

按優先順序選擇，即架構師綜合當前的業務發展情況、團隊人員規模和技能、業務發展預測等因素，將質量屬性按照優先順序排序，首先挑選滿足第一優先順序的，如果方案都滿足，那就再看第二優先順序……以此類推。

2. 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消費失敗不支援重試

RocketMQ消費失敗支援定時重試，每次重試間隔時間順延。

（8）定時/延時訊息

Kafka不支援定時訊息；

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來簡化系統實現的例子。

大家都在發展，功能的差異會很快抹平的。

RocketMQ 可以理解為是Java版 的kafka。

更多的效能對比可以參考阿里中介軟體團隊的報告。

轉載於:https://juejin.im/post/5cac5abde51d456e5633dda7

Kafka理論概述和應用場景

1.Kafka概述

Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料。簡單地說，Kafka就相比是一個郵箱，生產者是傳送郵件的人，消費者是接收郵件的人，Kafka就是用來存東西的，只不過它提供了一些處理郵件的機制。

2.Kafka相關名詞分析

• Broker：Kafka節點，一個Kafka節點就是一個broker，多個broker可以組成一個Kafka叢集
• Topic：一類訊息，訊息存放的目錄即主題，例如page view日誌、click日誌等都可以以topic的形式存在，Kafka叢集能夠同時負責多個topic的分發
• massage： Kafka中最基本的傳遞物件。
• Partition：topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的佇列
• Segment：partition物理上由多個segment組成，每個Segment存著message資訊
• Producer: 生產者，生產message傳送到topic
• Consumer: 消費者，訂閱topic並消費message, consumer作為一個執行緒來消費
• Consumer Group：消費者組，一個Consumer Group包含多個consumer
• Offset：偏移量，理解為訊息partition中的索引即可

下面做進一步說明：

broker即kafka程式，kafka程式運行於zookeeper之上，zookeeper是一個分散式的，分散式應用程式的協調服務，其提供的功能包括：配置維護、域名服務、分散式同步、組服務等。在此處，zookeeper協調kafka節點的配置、同步操作等。

topic即主題，kafka中釋出訊息、訂閱訊息的物件是topic。我們可以為每類資料建立一個topic。一個topic中的訊息資料按照多個partition組織，分割槽是kafka訊息佇列組織的最小單位(並不是物理上的最小單位)，一個分割槽可以看作是一個FIFO（ First Input First Output的縮寫，先進先出佇列）的佇列。如下圖：

例如，在上圖中，一個topic被分成了3個分割槽（即partition0~2），使用者釋出message時，可以指定message所處topic的partition，如果沒有指定，則隨機分佈到該topic的partition。釋出的訊息（其實是邏輯日誌）將在partition尾部插入。

segment是partition的物理儲存單元，kafka收到message後，會向對應partition的最後一個segment上新增該訊息，當某個segment上的訊息條數達到配置值或訊息釋出時間超過閾值時，segment上的訊息會被儲存到磁碟，只有被儲存到磁碟上的訊息consumer才能消費，segment達到一定的大小後將不會再往該segment寫資料，kafka會建立新的segment。其實，每個partition相當於分配到多個大小相等segment資料檔案中。但每個segment訊息數量不一定相等，這種特性方便無用的segment快速被刪除，segment檔案生命週期由服務端配置引數決定。如下圖：

consumer和consumer group，一個consumer group包含多個consumer,使用者可以指定consumer的group。各個consumer可以組成一個group，partition中的每個message只能被一個group中的一個consumer消費，如果一個message想要被多個consumer消費的話，那麼這些consumer必須在不同的group。kafka不支援一個partition中的message同時由兩個或兩個以上的consumer thread來處理，即便是來自不同的consumer group的也不行。kafka為了保證吞吐量，只允許一個consumer去訪問一個partition。如果覺得效率不高，可以加partition的數量來橫向擴充套件，再加新的consumer去消費，充分發揮了橫向的擴充套件性，吞吐量極高。這也就形成了分散式消費的概念。如下圖：

上圖中有兩個伺服器的kafka群集，它們有四個分割槽（P0-P3），其中有兩個group。group A有兩個消費者，group B有四個消費者。P0如果被C1消費後，則C2不能再消費，但是group B的C3或者其它的一個可以消費P0。

3.Kafka的優勢

• 高吞吐量、低延遲：kafka每秒可以處理幾十萬條訊息，它的延遲最低只有幾毫秒
• 可擴充套件性：kafka叢集支援熱擴充套件
• 永續性、可靠性：訊息被持久化到本地磁碟，並且支援資料備份防止資料丟失
• 容錯性：允許叢集中節點故障（若副本數量為n,則允許n-1個節點故障）
• 高併發：支援數千個客戶端同時讀寫

4.Kafka應用場景

• 日誌收集：一個公司可以用Kafka可以收集各種服務的log，通過kafka以統一介面服務的方式開放給各種consumer
• 訊息系統：解耦生產者和消費者、快取訊息等
• 使用者活動跟蹤：kafka經常被用來記錄web使用者或者app使用者的各種活動，如瀏覽網頁、搜尋、點選等活動，這些活動資訊被各個伺服器釋出到kafka的topic中，然後消費者通過訂閱這些topic來做實時的監控分析，亦可儲存到資料庫
• 運營指標：kafka也經常用來記錄運營監控資料。包括收集各種分散式應用的資料，生產各種操作的集中反饋，比如報警和報告
• 流式處理：比如spark streaming和storm；

RocketMQ —— 優點及基礎理論

更深入的瞭解RocketMQ一些優點，以及佇列的基礎知識。

設計優點

[Producer / Consumer] GROUP

RocketMQ中有一個“組”機制，此機制很重要，如下圖：

通過組機制(Group)，RocketMQ可以天然支援分散式。
如下所示：

如上圖所示，某個Topic有9條訊息，Consumer Group有三個例項（3個程序或3臺機器），9條訊息就會均攤到每個例項上（3條/個）!

【RocketMQ只有一個模式 ———— 釋出訂閱模式！】

RocketMQ 叢集部署模式