目錄

生產者消息確認機制

Kafka 生產者 ACK 機制

RocketMQ 生產者確認機制

消費者消息確認機制

Kafka 消費者確認機制

RocketMQ 消費者確認機制

核心差異對比

選型建議

---

消息確認機制是分布式消息中間件的核心功能之一，它直接關系到消息傳遞的可靠性和系統性能。下面我將從生產者和消費者兩個角度，詳細對比 Kafka 和 RocketMQ 的消息確認機制。

生產者消息確認機制

Kafka 生產者 ACK 機制

Kafka 提供了三種級別的生產者確認機制（ACK 機制），通過?acks?參數配置：

ACK 級別	描述	可靠性	性能	適用場景
acks=0	生產者發送消息后不等待任何確認	最低	最高	日志采集等對可靠性要求不高的場景
acks=1	等待 Leader 副本寫入本地日志后返回確認	中等	中等	實時監控等對可靠性和性能都有一定要求的場景
acks=-1?(或?all)	等待 ISR 中所有副本都寫入日志后返回確認	最高	最低	金融交易等對可靠性要求極高的場景

Kafka 的 ACK 機制還受到 ISR（In-Sync Replicas，同步副本集合）的影響。ISR 是與 Leader 保持同步的 Follower 副本集合，當 Leader 故障時會從 ISR 中選舉新的 Leader?。

RocketMQ 生產者確認機制

RocketMQ 提供了三種消息發送方式，對應不同的確認機制：

1. ?同步發送?：

   • 生產者發送消息后阻塞等待 Broker 返回?SendResult
   • 包含消息狀態（SEND_OK、FLUSH_DISK_TIMEOUT?等）
   • 默認重試 2 次（可通過?retryTimesWhenSendFailed?配置）
   • 可靠性最高，但性能較低?

2. ?異步發送?：

   • 通過回調函數?SendCallback?處理成功或異常
   • 性能介于同步和單向發送之間
   • 需要處理回調邏輯?

3. ?單向發送?：

   • 不關心發送結果，無確認機制
   • 性能最高，但可靠性最低
   • 適用于日志收集等場景?

消費者消息確認機制

Kafka 消費者確認機制

Kafka 的消費者確認是通過?位移（offset）提交?實現的：

1. 消費者為每個分區維護自己的消費位移（offset）
2. 消費者需要顯式提交 offset 以確認消息已成功處理
3. 提交方式：
   • ?自動提交?：定期自動提交（可能重復消費）
   • ?手動提交?：
     • 同步提交：commitSync()
     • 異步提交：commitAsync()
4. 如果消費者崩潰，將從最后提交的 offset 處重新消費?

RocketMQ 消費者確認機制

RocketMQ 的消費者確認機制更為顯式：

1. 消費者通過回調函數返回狀態確認消息：

   • ConsumeConcurrentlyStatus.CONSUME_SUCCESS：確認消費成功
   • ConsumeConcurrentlyStatus.RECONSUME_LATER：消費失敗，需要重試

2. ?重試機制?：

   • 失敗的消息會被發送到 RETRY topic
   • 默認重試 16 次，間隔可配置
   • 超過最大重試次數后進入死信隊列（DLQ）

3. ?順序消費?：

   • 順序消費回調不返回?RECONSUME_LATER
   • 而是暫停隊列等待消息重試成功?

核心差異對比

特性	Kafka	RocketMQ
?生產者確認?	通過?acks?參數配置級別（0/1/all）	通過發送方式決定（同步/異步/單向）
?消費者確認?	通過 offset 提交實現	通過顯式返回消費狀態實現
?重試機制?	依賴消費者重新消費	內置重試隊列和死信隊列
?順序保證?	分區內有序	隊列內有序，且提供嚴格順序消費模式
?設計側重?	高吞吐量	金融級可靠性

選型建議

• ?選擇 Kafka? 如果：

  • 需要極高的吞吐量
  • 可以接受一定程度的消息延遲
  • 系統已有 Kafka 技術棧

• ?選擇 RocketMQ? 如果：

  • 需要金融級可靠性保證
  • 需要靈活的重試和死信處理
  • 業務場景涉及事務消息

兩者在消息確認機制上的差異反映了它們不同的設計哲學：Kafka 更注重吞吐量和水平擴展，而 RocketMQ 更注重消息的可靠傳遞和事務支持。