English | 简体中文
DTM is a distributed transaction framework which provides cross-service eventual data consistency. It provides saga, tcc, xa, 2-phase message, outbox, workflow patterns for a variety of application scenarios. It also supports multiple languages and multiple store engine to form up a transaction as following:
- Support for multiple transaction modes: SAGA, TCC, XA, Workflow, Outbox
- Multiple languages support: SDK for Go, Java, PHP, C#, Python, Nodejs
- Better Outbox: 2-phase messages, a more elegant solution than Outbox, support multi-databases
- Multiple database transaction support: MySQL/MariaDB, Redis, MongoDB, Postgres, TDSQL, etc.
- Support for multiple storage engines: MySQL/MariaDB (common), Redis (high performance), BoltDB (dev&test), MongoDB (under planning)
- Support for multiple microservices architectures: go-zero, go-kratos/kratos, polarismesh/polaris
- Support for high availability and easy horizontal scaling
DTM can be applied to data consistency issues in a large number of scenarios, here are a few common ones
- cache management: thoroughly guarantee the cache final consistency and strong consistency
- flash-sales to deduct inventory: in extreme cases, it is also possible to ensure that the precise inventory in Redis is exactly the same as the final order created, without the need for manual adjustment
- Non-monolithic order system: Dramatically simplifies the architecture
- Event publishing/subscription: better outbox pattern
git clone https://github.com/dtm-labs/dtm && cd dtm
go run main.go
Suppose we want to perform an inter-bank transfer. The operations of transfer out (TransOut) and transfer in (TransIn) are coded in separate micro-services.
Here is an example to illustrate a solution of dtm to this problem:
git clone https://github.com/dtm-labs/quick-start-sample.git && cd quick-start-sample/workflow-grpc
go run main.go
wfName := "workflow-grpc"
err = workflow.Register(wfName, func(wf *workflow.Workflow, data []byte) error {
// ...
// Define a transaction branch for TransOut
wf.NewBranch().OnRollback(func(bb *dtmcli.BranchBarrier) error {
// compensation for TransOut
_, err := busiCli.TransOutRevert(wf.Context, &req)
return err
})
_, err = busiCli.TransOut(wf.Context, &req)
// check error
// Define another transaction branch for TransIn
wf.NewBranch().OnRollback(func(bb *dtmcli.BranchBarrier) error {
_, err := busiCli.TransInRevert(wf.Context, &req)
return err
})
_, err = busiCli.TransIn(wf.Context, &req)
return err
}
// ...
req := busi.BusiReq{Amount: 30, TransInResult: ""}
data, err := proto.Marshal(&req)
// Execute workflow
_, err = workflow.ExecuteCtx(wfName, shortuuid.New(), data)
logger.Infof("result of workflow.Execute is: %v", err)
When the above code runs, we can see in the console that services TransOut
, TransIn
has been called.
If any forward operation fails, DTM invokes the corresponding compensating operation of each sub-transaction to roll back, after which the transaction is successfully rolled back.
Let's purposely trigger the failure of the second sub-transaction and watch what happens
// req := busi.BusiReq{Amount: 30, TransInResult: ""}
req := busi.BusiReq{Amount: 30, TransInResult: "FAILURE"}
})
we can see in the console that services TransOut
, TransIn
, TransOutRevert
has been called
If you want more quick start examples, please refer to dtm-labs/quick-start-sample
The above example mainly demonstrates the flow of a distributed transaction. More on this, including practical examples of how to interact with an actual database, how to do compensation, how to do rollback, etc. please refer to dtm-examples for more examples.
If you think this project is interesting, or helpful to you, please give a star!