分布式事务

Workflow 模式是github.com/dtm-labs/dtm首创推出的模式，在这个模式下，可以混合使用XA、SAGA、TCC，也可以混合使用HTTP、gRPC

由于一个数据在 Redis 和数据库两处进行了存储，就会有数据一致性的问题，目前业界尚未见到成熟的能够确保最终一致性的方案。dtm+rockscache首次彻底解决了这个问题。

这种灵活的组合多个存储引擎Mysql、Redis、Mongo，形成一个分布式事务的能力，是dtm首创做到的，目前未看到其他的分布式事务框架有这样的能力。

AT 这种事务模式是阿里开源的seata主推的事务模式，本文会详解AT的原理，并将它与XA模式进行比较 原理 AT 从原理上面看，与 XA 的设计有很多相近之处。XA 是数据库层面实现的二阶段提交，

dtm-labs/dtm作为一款非常流行的分布式事务框架，已经支持了接入多种微服务框架，下面我们就来着重介绍一下go-kratos如何接入dtm，解决分布式事务的问题

本文提出的二阶消息，接口简洁优雅，带来了比本地消息表和 Rocket 事务消息更简单的架构，可以帮助大家更好的解决无需回滚的数据一致性问题。

一个具备两个事务分支的全局事务在Redis上的理论开销大约是4个Lua脚本的开销，那么从前面每秒能够完成大约6w个简单Lua脚本来看，最终弄1.08w个分布式事务已经差不多是极限值了

假设提交给dtm的事务中，调用转入操作时，出现短暂的故障怎么办？按照SAGA事务的协议，dtm会重试未完成的操作，这时我们要如何处理？故障有可能是转入操作完成后出网络故障，也有可能是转入操作完成中出现

我们从业务需求的角度，根据不同的业务场景，给出最适合的解决方案。 当我们采用服务/微服务架构，对业务进行分拆解耦后，就需要引入分布式事务来保证新的原子性

我们团队在引入go语言做微服务的过程中，遇见了分布式事务的强需求。开发了简单易用的分布式事务管理器并开源

什么是分布式事务？银行跨行转账业务是一个典型分布式事务场景，假设A需要跨行转账给B，那么就涉及两个银行的数据，无法通过一个数据库的本地事务保证转账的ACID，只能够通过分布式事务来解决。 分布式事

随着业务的快速发展、业务复杂度越来越高，几乎每个公司的系统都会从单体走向分布式，特别是转向微服务架构。随之而来就必然遇到分布式事务这个难题，这篇文章总结了分布式事务最经典的解决方案，分享给大家。