add doc/protocol-en.md
This commit is contained in:
今吾
parent
73d5fe8690
commit
472bfb1c1c
19
README-en.md
19
README-en.md
@ -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"
|
||||
@ -61,7 +62,7 @@ Configure mysql：
|
||||
Refer to [examples/quick_start.go](./examples/quick_start.go)
|
||||
|
||||
### Wechat Group
|
||||
Please add wechat yedf2008 friends or scan the code to add friends
|
||||
Please add wechat yedf2008 friends or scan the code to add friends
|
||||
|
||||
|
||||
|
||||
|
||||
38
doc/protocol-en.md
Normal file
38
doc/protocol-en.md
Normal 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).
|
||||
@ -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事务失败回滚
|
||||
- 其他则需要重试（结果不确定，需要重试）
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user