Kakfa 官方宣稱支持事務(wù)消息，但是官方的“事務(wù)消息”和我們需要的事務(wù)消息往往不同。

• Kafka 官方事務(wù)消息：解決的是在一次事務(wù)中需要發(fā)送多條消息的情況，保證多個(gè)消息之間的事務(wù)約束。即多條消息要么都發(fā)送成功，要么都發(fā)送失敗。

• RocketMQ事務(wù)消息：解決的是本地事務(wù)的執(zhí)行和發(fā)消息著兩個(gè)動(dòng)作的事務(wù)一致性問題。

我們一般需要的是RocketMQ這種事務(wù)消息，如寫MySQL和發(fā)MQ消息兩個(gè)動(dòng)作保證事務(wù)性。

Kafka 實(shí)現(xiàn)事務(wù)消息的思路

通過2PC的方式向Kafka Broker提交消息可以實(shí)現(xiàn)事務(wù)消息。

通過上圖可以看到，生產(chǎn)者啟用事務(wù)消息后，第一次向Broker發(fā)送的是一個(gè)半消息，對(duì)消費(fèi)者不可見。只有生產(chǎn)者第二次通知Broker提交消息后，此消息才對(duì)消費(fèi)者可見。而半消息是否提交是由生產(chǎn)者側(cè)的本地事務(wù)執(zhí)行情況決定的。

推演

• 步驟1 發(fā)送半消息 失敗 / 超時(shí)：消息生產(chǎn)者等待一段時(shí)間沒有收到Broker的消息可重試。

• 步驟2?MQ Server?收到消息但回復(fù)丟失了：消息生產(chǎn)者可以重試。重試并不會(huì)最終在Broker中提交兩條相同消息。通過唯一id的方式，可以保證同一條消息即使生產(chǎn)者多次發(fā)送在Broker中也只會(huì)存在唯一一條記錄。

• 步驟3 本地事務(wù)執(zhí)行失?。篗Q 發(fā)送方 要求MQ Server丟棄半消息（即步驟4 rollback）。

• 步驟4 MQ發(fā)送方要求MQ Server 提交半消息丟失：MQ Server 超時(shí)未收到步驟4的commit / rollback，通過回調(diào)接口主動(dòng)查詢本地事務(wù)的狀態(tài)（步驟5 和 步驟6）。