Distributed MySQL Transaction

README.md

2PC

1. Define Transaction Manager as TM, define Resource Manager as RM
2. Business send request to TM to start a new transaction
3. TM send msg to RM to prepare a transaction
4. if all RM response ok, go to next step; if any RM fails, TM will send rollback to all RM
5. TM send commit to all RM, if any RM fails, TM will send rollback to all RM
6. All RM commited transaction

3PC

1. Define Transaction Manager as TM, define Resource Manager as RM
2. Business send request to TM to start a new transaction
3. TM send canCommit to all RM, TM switch to waiting state.
4. If RM agree, return YES to TM and switch to prepared state, if exception ocurrs, switch to abort
5. TM receives response from all RM, if ok, TM send preCommit to all RMs, and switch to prepared state; if not ok, send abort to all RMs
6. RMs receive preCommit, responses ACK to TM.
7. TM receives most part of RMs' ACK, switch to commit state, and send doCommit to all RMs, if timeout occurs to wait an ACK from RMs, TM will abort the whole transaction
8. RMs receive doCommit and send ACK to TM, if RMs cannot receive a doCommit, it'll also commit the local transaction.

Forward idempotent retry + reverse asynchronous callback(Best effort notification type)

1. client query for state
2. service query mysql, if record found, and then response to client; if no record found, send a synchronous request to downstream, record response status quering, succeed or failed.
3. if failed, retry, if succeed, update record to succeed

Reliable message services(Message service)

1. Business start transaction, write to message service with init
2. Business Operation
3. Business Commit transaction, and modified message status to wait
4. Message service use Timing Polling to handle:
5. init, it maybe timeout transaction, cancel it and notice Business service
6. wait, send to MQ(kafka)
7. Kafka consumer pull msg and execute, need to ensure Idepotence
8. Once consumer succeed, return ACK to Kafka and to message service
9. Message service modified message status to succeed

Reliable message services(Local msg table)

1. Business start transaction
2. Business operation
3. Write to local msg table with wait
4. Commit transaction
5. Business start a timing polling thread to poll local msg table
6. Timing polling thread find the record with wait status, send it to Kafka
7. Kafka consumer pull msg and execute, need to ensure Idepotence
8. Once consumer succeed, return ACK to Kafka and to business service
9. business service modified msg to succeed

if there is a fail at any moment, just do a rollback

TCC

1. Primary business send TryRequest to secondary business
2. Secondary business execute local transaction and commit, response to Primary business
3. If TryRequest succeed, Primary send confirm to secondary business; if failed, Primary send Cancel to secondary business
4. Secondary execute a compensation transaction to withdral the resource in TryRequest