An Awesome Distributed Transaction Middleware, Support Any Language!

#distributedsystems #microservices #cloudnative #database

The DBPack is an DB mesh resolution that implements in AT transaction mode, which is a distributed transaction model that has no invasion into the business logic and has high performance.

Github repo: https://github.com/CECTC/dbpack

You can learn more AT transaction in this site.

The DBPack is a little bit different from Seata AT transaction, it can be deployed as a sidecar in k8s, so that any programming language can use this sidecar to handle distributed transaction. It also support sharding DB and tables and more features are coming soon.

Here is a picture to describe the DBPack work flow, hope it can help you understand it better.

Here is the workflow description:

Slient sends HTTP request to DBPack proxy of Aggregation Service. (Note: request address and port should configuraed be DBPack proxy instead of actual Aggregation Service API address).
DBPack generates unique XID (global transaction id), and stores it in ETCD.
If global transaction begins successfully (will end transaction in case failed), the Aggregation Service can get XID through HTTP header (X-Dbpack-Xid). Then the Aggregation Service can send API request to Service1 and pass XID to it.
After Service1 receives the XID, it send business SQL to DBPack, the proxy will register branch transaction for Service1 (generate branchID, store in ETCD...)
After the Service1 been registered, the DBPack will generate undo_log for the business SQL, then the undo_log will commit along with local transaction of Service1.
Service2 will do the same step4, 5 as Service1.
The Aggregation Service can get the API result from Service1 and Service2, and decides if to global commit or rollback. In case both API success, it response HTTP 200 to DBPack. In case failed, it response other status code except 200. The DBPack will update global transaction to "commiting" or "rollbacking" in ETCD accordingly.
Through ETCD watch mechanism, Service1 and Service2 will know if to commit or rollback their branch transaction. (In case commit, they delete the undo_log; In case rollback, they execute the undo_log.)
After all branch been commited or rollbacked, the branch status will get updated in ETCD. The DBPack proxy of Aggregation Service will know that the global transaction is finished, then it will delete XID and BranchID info from ETCD.