[Miscellaneous Talk] Distributed Transactions

How to ensure the atomicity of multiple database operations?

It's very simple, use transactions. Specifically for the code, add a @Transactional to the method, so that the entity operations inside the method can be within a data transaction.

Abc three entities, either modify all or not.

@Transactional
public void someOperation() {
        (a);
        (b);
        (c);
}

So what if there is an entity modification on another service?

AssumptionsbThis data belongs to another microservice, we useFeignClientCall it remotely:

@Transactional
public void someOperation() {
        (a);
        (b);
        (c);
}

Then @Transactional can only ensure the atomicity of the two modifications a and c, and the modification of b is not controlled.

Solutions for distributed transactions

Distributed transactions are usually processed using two-stage commits (2PC, Two-Pahse Commit).

1.Prepare stage (Prepare stage)

Transaction Coordinator (TC, Transaction Coordinator) notifies all participants (branch transactions) to perform transaction operations, but does not commit
Each participant performs a local transaction and logs an undo log (or locks the resource) and then reports to TC the preparation success or failure
- Use a row of data to lock using a row level lock (SELECT ... FOR UPDATE) and cannot be modified by other threads.

2.Stage 2 (Commit/Rollback, commit or rollback stage)

If all participants are ready for success, TC notifies all branch transactions to commit
If any of them fails, TC notifies all branch transactions to rollback.

As far as code is concerned, assume that the XA command is not used.
A branch transaction will execute these 5 SQL sentences in turn. Generally, after the execution is successful, it will stop and no longer send new SQL to the database.
The branch transaction will wait for the command of the coordinator TC. If it can be executed, it will continue to execute COMMIT, otherwise it will execute ROLLBACK.

-- 1. Start transactions
START TRANSACTION;

-- 2. Lock the target data first to ensure that there will be no concurrent modifications for other transactions in the future
SELECT * FROM table_b WHERE id = '12345' FOR UPDATE;

-- 3. Record old data to `undo_log`
INSERT INTO undo_log (table_name, record_id, old_value)
SELECT 'table_b', id, name FROM table_b WHERE id = '12345';

-- 4. Perform update operation
UPDATE table_b SET name='www' WHERE id= '12345';

-- 5. Wait for the TC instruction:
-- ✅ If TC says "can submit", then execute:
COMMIT;

-- ❌ If TC says "rollback", execute:
ROLLBACK;

If other branch transactions fail after COMMIT, the data can be rolled back and forth through the undo_log table.

Distributed Transaction Framework——Seata

High-performance AT mode

In the first stage, Seata directly modifys the database (unlike 2PC, it does not lock resources)
- Seata will intercept SQL and record undo log (data before modification), which is used to rollback
In the second phase:
- When submitting: submit directly, no additional operations
- When rolling back: use undo log to restore data

Compared with traditional 2PCs, it avoids long-term locking of resources and improves performance.

Case code:

@GlobalTransactional
public void someOperation() {
        (a);
        (b);
        (c);
}

With a high-performance framework like Seata, why are distributed transactions still uncommon?

1. Businesses usually do not require strong consistency, only final consistency

Most business scenarios do not have that strict data consistency requirements.As long as the final consistency can be achieved within a period of time, that's enough.

Case: User balance recharge and coupon issuance

Suppose you recharge 100 yuan on an e-commerce platform and the platform stipulates:The first recharge of more than 100 yuan will be given a 10 yuan coupon。

Assume that the recharge and discount coupon distribution are on two independent services, it is possible to write MQ after the recharge is completed, and then the discount coupon service can process the message.

As long as the final result is consistent.

2. Transaction localization

When splitting microservices, transaction operations are usually classified into one service and will not cross-services.

For example, a system has payment-related operations in a payment service.

Additional overhead still exists

For example, additional SQL parsing; maintenance of undo log tables, additional database writing; additional network communication.