DTM 是首款 golang 的开源分布式事务管理器，优雅的解决了幂等、空补偿、悬挂等分布式事务难题。在微服务架构中，提供了高性能和简单易用的分布式事务解决方案。
亮点
- 稳定可靠
- 经过生产环境考验，单元测试覆盖率90%以上
- 使用简单
- 接口简单，开发者不再担心悬挂、空补偿、幂等各类问题，框架层代为处理
- 跨语言
- 可适合多语言栈的公司使用。协议支持http。方便go、python、php、nodejs、ruby各类语言使用。
- 社区活跃
- 任何问题都快速响应
- 易部署、易扩展
- 仅依赖mysql，部署简单，易集群化，易水平扩展
- 多种分布式事务协议支持
- TCC: Try-Confirm-Cancel
- SAGA:
- 可靠消息
- XA
与其他框架对比
目前开源的分布式事务框架，有阿里的 SEATA、华为的 ServiceComb-Pack，京东的 shardingsphere，以及 himly，tcc-transaction，ByteTCC 等等，其中以 seata 应用最为广泛。
这些框架基本都是 Java 语言，非 Java 语言的，暂未看到有成熟的框架。
下面将dtm和seata的主要特性做一下对比：
快速开始
安装
git clone https://github.com/yedf/dtm
dtm依赖于mysql
配置mysql：
cp conf.sample.yml conf.yml # 修改conf.yml
启动并运行saga示例
go run app/main.go saga
-
第一步：dtm源码编译安装 git clone https://github.com/dtm-labs/dtm && cd dtm 或手动下载https://github.com/dtm-labs/dtm 编译器：goland 运行： 同级目录下有main.go 执行编译（go run main.go），第一次需要下载依赖git包 编译： windows下默认编译生成.exe的可执行程序,linu
-
我有两个微服务和调用来更新数据，然后插入另一个数据，但让我们考虑一下 失败，然后我们需要回滚由 更新的数据，否则我们将处于不一致的状态。 我也经历了佐贺patterns.will它满足了这种矛盾 谁能为此提出更好的解决方案？
-
最近在学微服务的分布式事务，不太明白为什么在微服务这种分布式系统中，原有的单体acid会出现问题 希望大佬们可以讲一下原理和思想
-
ShardingSphereTransactionManager SPI 名称 详细说明 ShardingSphereTransactionManager 分布式事务管理器 已知实现类 详细说明 XAShardingSphereTransactionManager 基于 XA 的分布式事务管理器 SeataATShardingSphereTransactionManager 基于 Seata 的分
-
ShardingSphere-Proxy 接入的分布式事务 API 同 ShardingSphere-JDBC 保持一致，支持 LOCAL，XA，BASE 类型的事务。 XA 事务 ShardingSphere-Proxy 原生支持 XA 事务，默认的事务管理器为 Atomikos。 可以通过在 ShardingSphere-Proxy 的 conf 目录中添加 jta.properties 来定
-
通过 Apache ShardingSphere 使用分布式事务，与本地事务并无区别。 除了透明化分布式事务的使用之外，Apache ShardingSphere 还能够在每次数据库访问时切换分布式事务类型。 支持的事务类型包括 本地事务、XA事务 和 柔性事务。可在创建数据库连接之前设置，缺省为 Apache ShardingSphere 启动时的默认事务类型。
-
背景 数据库事务需要满足 ACID（原子性、一致性、隔离性、持久性）四个特性。 原子性（Atomicity）指事务作为整体来执行，要么全部执行，要么全不执行。 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另一个一致的状态。 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不应影响其他事务的执行。 持久性（Durability）指已提交的事务修改数据会被持久
-
单文档原子性可满足大多数业务需求 在 MongoDB 中，对单个文档的操作是原子操作。 由于 MongoDB 文档数据模型，一个文档中通过嵌入式的文档和数组来表示传统关系数据库模型中的一对一、一对多关系，而不是通过文档之间的复杂关系来描述业务需求中的一对一、一对多关系。 所以单文档原子性可以满足实际生产中大多数关于事务的需求。 对于需要对多个文档（在单个或多个集合中）进行原子读写的情况，Mongo
-
两阶段提交协议 通常在复杂场景下是不推荐使用的，除非是非常简单的场景，非常容易提供回滚，而且依赖的服务也非常少的情况。 这种实现方式会造成代码量庞大，耦合性高。而且非常有局限性，因为有很多的业务是无法很简单的实现回滚的，如果串行的服务很多，回滚的成本实在太高。 本地消息表 这种实现方式的思路，其实是源于ebay，后来通过支付宝等公司的布道，在业内广泛使用。其基本的设计思想是将远程分布式事务拆分成一