Laravel implements distributed transactions based on RT mode

Quick preview

Install the version between laravel5.5 - laravel8, then install the composer package

## Must use composer2 version
composer require windawake/laravel-reset-transaction dev-master

First create order, storage, account 3 mysql database instances, 3 controllers, 3 models, add testsuite Transaction in phpunit.xml, and then start the web server. These operations only need to execute the following command to complete all

php artisan resetTransact:create-examples && php artisan serve --host=0.0.0.0 --port=8000

Open another terminal and start the transaction center with port 8001, or it can be replaced with the go version transaction center https://github.com/windawake/gortcenter

php artisan serve --host=0.0.0.0 --port=8001

Finally run the test script ./vendor/bin/phpunit --testsuite=Transaction --filter=ServiceTest The running result is shown below, and the 3 examples have passed the test.

DESKTOP:/web/linux/php/laravel/laravel62# ./vendor/bin/phpunit --testsuite=Transaction --filter=ServiceTest
Time: 219 ms, Memory: 22.00 MB

OK (3 tests, 12 assertions)

Features

1. Out-of-the-box, no need to refactor the code of the original project, consistent with the mysql transaction writing, easy to use.
2. Two-stage committed transactions with strong consistency, under high concurrency, support read-committed transaction isolation level, and data consistency is almost 100%.
3. The performance is better than the seata AT mode. Since the transaction is split into multiple, it becomes several small transactions. The stress test finds that there are fewer deadlocks than ordinary MySQL transactions.
4. Support distributed transaction nesting, consistent with savepoint.
5. Support to avoid the problem of dirty data caused by concurrency of different business codes.
6. The service interface of the http protocol is supported by default. If you want to support other protocols, you need to rewrite the middleware.
7. [Support sub-service nested distributed transactions (breakthrough technology)] (#Support sub-service nested distributed transactions (breakthrough technology)).
8. Support services, mixed nesting of local transactions and distributed transactions
9. Support 3 retries over time, repeat requests to ensure idempotency
10. Almost all SQL statements are supported, which can be inserted in batches, updated in batches, and deleted in batches (breakthrough technology)
11. Support detection of locks caused by xa prepare and release xa locks more accurately
12. Support go, java language (under development)
13. Distributed transaction visual management background (under development)

What concurrency scenarios are solved

• [x] An order to be shipped, the user operates both shipping and canceling the order, only one is successful
• [x] Exchange of points for coupons, as long as the points are not enough to be deducted or the inventory of coupons is not enough to be deducted, it will all fail.

Principle analysis

Reset Transaction, the Chinese name is reset distributed transaction, also named RT mode, and seata AT mode both belong to two-stage submission. It has the same meaning as "traversing" in Chinese TV series.
If you have seen the movie "Edge of Tomorrow", you will know the operation of archiving and reading files. This distributed transaction component imitates the principle of the movie "Edge of Tomorrow". Every time the basic service is requested, the file is read at the beginning, and then the subsequent operations are continued. At the end, all operations are rolled back and archived, and the final step commit executes all the archives successfully. The whole process is to comply with the two-stage submission protocol, first prepare, and finally commit.

Taking the scenario of creating an order and deducting an inventory as an example, the following flowchart is drawn.

After the distributed transaction RT mode is turned on in the right picture, there are 4 more requests than the left picture. Everything done by request 4 is what was done before requests 1-3, and it goes back to the origin and starts again, and finally submits the transaction, ending the process of creating an order.

Support sub-service nested distributed transactions (breakthrough technology)

A world-class problem: A service commit->B service rollback->C service commit->D service commit sql, in this scenario, ABCD are different databases, how can we make A service submit B service and rollback What about all the operations of the C service and the D service?

Neither seata nor go-dtm can solve this problem. The key point to solve the problem is that the C service and the D service must be falsely submitted, and cannot be submitted for real.

What are the benefits of implementing support for sub-service nested distributed transactions? A service can be made to be someone else's service, and it can be nested at any level in the link. Breaking the previous constraints: Service A must be a root service, and if service A wants to become a sub-service, the code must be changed greatly. If RT mode is used, service A can become someone else's service without modifying the code.

how to use

In the laravel framework, distributed transactions can be realized by replacing the facade DB with RT.

<?php
use Illuminate\Support\Facades\DB;
use Laravel\ResetTransaction\Facades\RT;
DB::beginTransaction();
...
DB::commit();
#replace
RT::beginTransaction();
...
RT::commit();

#detailed example
RT::beginTransaction();
(new Client)->put('http://127.0.0.1:8000/api/resetOrder/11', [
'json' => [
'order_no' => 'aaa',
],
'headers' => [
'rt_request_id' => session_create_id(), // support idempotent
'rt_transact_id' => RT::getTransactId(), //Let the order service know that it is currently inside a distributed transaction
]
]);
RT::commit();

For specific examples, see the code of vendor/windawake/laravel-reset-transaction/examples/tests/Transaction/ServiceTest.php in the composer package.