add doc/protocol-en.md

This commit is contained in:
今吾 2021-07-22 11:46:47 +08:00
parent 73d5fe8690
commit 472bfb1c1c
3 changed files with 57 additions and 18 deletions

View File

@ -6,10 +6,10 @@
[中文版](https://github.com/yedf/dtm/blob/main/README.md)
# a golang distributed transaction manager
# A golang distributed transaction manager
DTM is the first golang open source distributed transaction project. It elegantly resolve the problem of execution out of order. In the microservice architecture, a high-performance and easy-to-use distributed transaction solution is provided.
## characteristic
## Characteristic
* Stable and reliable
+ Tested in the production environment, unit test coverage is over 90%
@ -26,22 +26,23 @@ DTM is the first golang open source distributed transaction project. It elegantl
+ XA
### [sub-transaction barrier](./doc/barrier-en.md)
### [protocol](./doc/protocol-en.md)
# Quick start
### installation
### Installation
`git clone https://github.com/yedf/dtm`
### dtm depends on mysql
### DTM depends on mysql
Configure mysql
Configure mysql:
`cp conf.sample.yml conf.yml # 修改conf.yml`
`cp conf.sample.yml conf.yml # Modify conf.yml`
### Start and run the saga example
`go run app/main.go`
# start using
# Start using
### use
### Use
``` go
// business microservice address
const qsBusi = "http://localhost:8081/api/busi_saga"

38
doc/protocol-en.md Normal file
View File

@ -0,0 +1,38 @@
## DTM Communication Protocol
### Role
A dtm transaction has three roles
- RM-Resource Manager: Manage system resources. The database is a resource manager that handles management resources and should also have the ability to manage transaction commit and rollback.
* RM manages sub-transactions in distributed transactions, and is responsible for operations such as modification, submission, rollback, and compensation of related data. Usually corresponds to a microservice.
- TM-Transaction Manager: The transaction manager is the core manager of distributed transactions. The transaction manager communicates with each RM (Resource Manager) to coordinate and complete transaction processing.
* Every global transaction is registered in TM, and every sub-transaction is also registered in TM. TM will coordinate all RMs, commit all different sub-transactions of the same global transaction, or roll back all of them.
- AP-Application Program: The application program calls the RM interface according to the business rules to complete the changes to the business model data.
* The AP will register the global transaction, register the sub-transactions according to the business rules, and call the RM interface. Usually corresponds to a microservice.
In the case of nested sub-transactions, a microservice will play the roles of RM and AP at the same time, as shown in the figure
<img src="https://pic1.zhimg.com/80/v2-b6645d3aedefe42ffe8395faa1a94224_1440w.png" alt="diagram">
### Protocol
Currently dtm only supports the http protocol. Since distributed transactions involve the collaboration of multiple roles, some participants may be temporarily unavailable and need to be retried; some participants clearly inform that they have failed and need to be rolled back.
The following is a classification description of each situation, and the return value of each situation is defined. The design mainly draws on the interface of WeChat/Alipay order success callback. They also return SUCCESS to indicate success and do not retry.
In the above figure, there are mainly the following types of interfaces:
AP calls the TM interface, mainly for global transaction registration, submission, and sub-transaction registration, etc.:
- Success: { dtm_result: "SUCCESS" }
- Failure: { dtm_result: "FAILURE" }, indicates that the status of this request is incorrect, for example, a failed global transaction is not allowed to register branches.
- Other errors need to be tried again.
TM calls the RM interface, mainly for the two-phase commit, rollback, and each branch of saga
- Success: { dtm_result: "SUCCESS" }, indicates that this interface is successfully called, and proceed to the next step normally.
- Failure: { dtm_result: "FAILURE" }, indicates that this interface call failed and the business needs to be rolled back. For example, if the action in saga returns FAILURE, the entire saga transaction fails and rolls back.
- Others need to retry (The result is uncertain, need to retry).
AP calls the RM interface, which is related to the business, and the recommended interface form (not required):
- Success: { dtm_result: "SUCCESS" }, indicates that this interface is successfully called, and proceed to the next step normally. The returned result can also contain other business data.
- Failure: { dtm_result: "FAILURE" }, indicates that this interface call failed and the business needs to be rolled back. For example, if the Try action in tcc returns FAILURE, the entire tcc transaction fails and rolls back.
- Others need to retry (The result is uncertain, need to retry).

View File

@ -22,16 +22,16 @@
上面的图中,主要有以下几类接口:
AP调用TM的接口主要为全局事务注册、提交子事务注册等
- 成功: {dtm_result:"SUCCESS"}
- 失败: {dtm_result:"FAILURE} 表示这个请求状态不对例如已经走fail的全局事务不允许再注册分支
- 成功: { dtm_result: "SUCCESS" }
- 失败: { dtm_result: "FAILURE" }表示这个请求状态不对例如已经走fail的全局事务不允许再注册分支
- 其他错误则需要重试
TM调用RM的接口主要为二阶段的提交、回滚以及saga的各分支
- 成功: {dtm_result: "SUCCESS"} 表示这个接口调用成功,正常进行下一步操作
- 失败: {dtm_result: "FAILURE"} 表示这个接口调用失败业务需要进行回滚。例如saga中的动作如果返回FAILURE则整个saga事务失败回滚
- 其他则需要重试 // 结果不确定,需要重试
- 成功: { dtm_result: "SUCCESS" }表示这个接口调用成功,正常进行下一步操作
- 失败: { dtm_result: "FAILURE" }表示这个接口调用失败业务需要进行回滚。例如saga中的动作如果返回FAILURE则整个saga事务失败回滚
- 其他则需要重试(结果不确定,需要重试)
AP调用RM的接口跟业务相关建议的接口形式,非必须
- 成功: {dtm_result: "SUCCESS"},表示这个接口调用成功,正常进行下一步操作。返回的结果还可以包含其他业务数据。
- 失败: {dtm_result: "FAILURE"}表示这个接口调用失败业务需要进行回滚。例如tcc中的Try动作如果返回FAILURE则整个tcc事务失败回滚
- 其他则需要重试 // 结果不确定,需要重试
AP调用RM的接口跟业务相关建议的接口形式(非必须):
- 成功: { dtm_result: "SUCCESS" },表示这个接口调用成功,正常进行下一步操作。返回的结果还可以包含其他业务数据。
- 失败: { dtm_result: "FAILURE" }表示这个接口调用失败业务需要进行回滚。例如tcc中的Try动作如果返回FAILURE则整个tcc事务失败回滚
- 其他则需要重试(结果不确定,需要重试)