1 Kafka的事務 V.S RocketMQ
RocketMQ事務主要解決問題：確保執行本地事務和發訊息這倆操作都成功/失敗。RocketMQ還有事務反查機制兜底，更提高事務執行的成功率和資料一致性。
而Kafka事務，是為確保在一個事務中傳送的多條訊息，要麼都成功，要麼都失敗。
這裡的多條訊息不一定在同一個topic和partition，可以是發往多個topic和partition的訊息。當然，你可在Kafka事務執行過程中，加入本地事務，來實現和RocketMQ事務類似效果，但Kafka沒有事務反查機制。
Kafka這種事務機制，單獨使用場景不多。更多是配合Kafka冪等機制，實現Kafka的Exactly Once語義。這裡Exactly Once和一般MQ服務水平的Exactly Once不同！
1.1 Exactly Once
一般MQ服務水平中的，指訊息從Pro傳送到Broker，Con再從Broker拉訊息消費。這過程中，確保每條訊息恰好傳輸一次，不重複、不丟棄。
1.2 At Least Once
包括Kafka在內的幾個常見MQ，都只能做到At Least Once（至少一次），即保證訊息不丟，但可能重複，達不到Exactly Once。
2 Kafka的Exactly Once
使用場景：解決流計算中，用Kafka作資料來源，並將計算結果儲存到Kafka。資料從Kafka的某topic中消費，在計算叢集中計算，再把計算結果儲存在Kafka的其他topic。
這樣的過程中，保證每條訊息都被恰好計算一次，確保計算結果正確。
2.1 案例
將所有訂單訊息儲存在Kafka主題Order，在Flink叢集中執行一個計算任務，統計每分鐘的訂單收入，然後把結果儲存在另一個Kafka主題Income。
要保證計算結果準確，就要確保無論Kafka叢集 or Flink叢集中任何節點故障，每條訊息都只能被計算一次，不能重複計算，否則計算結果就錯。很重要的限制條件：資料須來自Kafka且計算結果都儲存到Kafka，才可應用到Kafka的Excactly Once機制。
所以Kafka的Exactly Once是為解決在“讀資料-計算-儲存結果”的計算過程中，資料不重也不丟，並非一般MQ訊息生產消費過程中的Exactly Once。
3 Kafka的事務實現
實現原理和RocketMQ事務差不多，都基於兩階段提交。為解決分散式事務，Kafka引入
3.1 事務協調者
在服務端協調整個事務。非獨立程序，而是Broker程序的一部分，協調者和分割槽一樣透過選舉保證HA。
類似RocketMQ，Kafka叢集也有一個特殊的用於記錄事務日誌的topic，該事務日誌topic的實現和普通topic一樣，裡面記錄資料類似“開啟事務”“提交事務”這樣的事務日誌。日誌topic同樣也包含很多分割槽。
Kafka叢集中，可存在多個協調者，每個協調者負責管理和使用事務日誌中的幾個分割槽。就是為能並行執行多個事務，提升效能。
3.2 Kafka事務實現流程
開啟事務時，pro給協調者發請求開啟事務，協調者在事務日誌中記錄下事務ID。
然後，pro發訊息前，還要給協調者發請求，告知傳送的訊息屬於哪個主題和分割槽，這個資訊也會被協調者記錄在事務日誌。
接下來，pro就可像傳送普通訊息一樣發事務訊息，和RocketMQ不同在於：
- RocketMQ把未提交的事務訊息儲存在特殊queue
- 而Kafka在處理未提交的事務訊息時，和普通訊息一樣，直接發給Broker，儲存在這些訊息對應的分割槽中，Kafka會在客戶端的Con中，暫時過濾未提交的事務訊息
訊息傳送完成後，pro給協調者傳送提交或回滾事務的請求，由協調者來開始兩階段提交，完成事務：
- 第一階段，協調者把事務的狀態設定為“預提交”，並寫入事務日誌。至此，事務實際上已經成功，無論接下來發生什麼，事務最終都會被提交
- 第二階段，協調者在事務相關的所有分割槽中，都會寫一條“事務結束”的特殊訊息，當Kafka的消費者，也就是client，讀到該事務結束的特殊訊息後，就可把之前暫時過濾的那些未提交的事務訊息，放行給業務程式碼消費
- 最後，協調者記錄最後一條事務日誌，標識該事務已結束
3.3 事務執行時序圖
3.4 準備階段
生產者發訊息給協調者開啟事務，然後訊息傳送到每個分割槽上
3.5 提交階段
生產者發訊息給協調者提交事務，協調者給每個分割槽發一條“事務結束”的訊息，完成分散式事務提交。
4 總結
Kafka基於兩階段提交來實現事務，利用特殊的主題中的佇列和分割槽來記錄事務日誌。Kafka直接把訊息放到對應業務分割槽中，配合客戶端過濾，暫時遮蔽進行中的事務訊息。
Kafka的事務則是用於實現它的Exactly Once機制，應用於實時計算的場景中。
參考
- https://www.confluent.io/blog/transactions-apache-kafka/
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。
各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&券等營銷中臺建設
- 交易平臺及資料中臺等架構和開發設計
- 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
- LLM Agent應用開發
- 區塊鏈應用開發
- 大資料開發挖掘經驗
- 推薦系統專案
目前主攻市級軟體專案設計、構建服務全社會的應用系統。
參考：
- 程式設計嚴選網
本文由部落格一文多發平臺 OpenWrite 釋出！