발췌 : https://www.cnblogs.com/iceggboom/p/12144570.html
분산 트랜잭션 프레임 워크 -seata 아는 사람
첫째, 트랜잭션 및 분산 트랜잭션
업무는 데이터베이스의 중간에 데이터베이스의 작업의 가장 작은 단위이며,보고 큰에, 트랜잭션이 모든 작업 그렇지 않으면 각 작업에서 만든, 성공적으로 완료해야하는 작업의 엄격한 응용 프로그램의 일련의 모든 변경은 취소입니다.
왜 분산 트랜잭션 (transaction)가있다? 단일 트랜잭션 세션 ACID에 내 운영 제한하여 데이터베이스 자체 로그를 잠금으로써 달성 될 수있다. 때문에 분산 아키텍처의 도입으로, 트랜잭션, 트랜잭션 서버 지원, 자원의 참가자 그래서 서버와 트랜잭션 관리자는 분산 시스템의 서로 다른 노드에있는 것은 다르다. 단순히 각각의 운영이 성공하거나 실패 할 수 있도록하기 위해 여러 데이터베이스 사이 보장하는 것은 아닙니다.
둘째, 도입
Seata는 : 간단한 확장 자율 트랜잭션 건축, 간단하고 확장 가능한 자율 분산 트랜잭션 관리 프레임 워크는, 그것의 전임자는 fescar했다. 오픈 소스 구현의 알리바바 GTS 버전은 분산 트랜잭션을위한 솔루션입니다.
셋째, 아키텍처
- 코디네이터 코어 : 가장 낮은 트랜잭션 코디네이터 모듈 핵심 코드는 주로 커밋 여부로, 트랜잭션 조정 로직에 사용되는, 롤백 활동의 조정 등이있다.
- 저장소 : 우리의 데이터 지속성, 다시 시작하거나 다운 타임의 저장 모듈은 데이터 손실을 방지 할 수 있습니다.
- 발견 : 클라이언트에 서버 주소를 노출 서비스 등록 / 검색 모듈.
- 구성은 : 저장하고 서버의 구성을 찾는 데 사용.
- 잠금 : 잠금 모듈은 Seata에게 글로벌 잠금 기능을 제공하는 데 사용됩니다.
- RPC : 및 통신의 다른 쪽 끝을합니다.
- HA 클러스터 : 고 가용성 클러스터는 현재 오픈 소스가 아닙니다. Seata에 대한 신뢰할 수있는 고 가용성 기능을 제공합니다.
넷째, 워크 플로우
1) 역할에 참여
Transaction Coordinator(TC)：管理全局的分支事务的状态，用于全局性事务的提交和回滚。
Transaction Manager(TM)：事务管理器，用于开启全局事务、提交或者回滚全局事务，是全局事务的开启者。
Resource Manager(RM)：资源管理器，用于分支事务上的资源管理，向TC注册分支事务，上报分支事务的状态，接受TC的命令来提交或者回滚分支事务。
2)流程
- TM向TC请求发起一个全局事务，TC返回一个代表这个全局事务的XID。
- XID在rpc中传播给每一个调用链中的服务。
- 每个RM拿到XID后向TC发起一个分支事务，TC返回一个代表这个分支事务的XID。
- RM完成本地分支的业务，提交本地分支，并且报告给TC。
- 全局事务调用链处理完毕，TM根据有无异常向TC发起全局事务的提交或者回滚。
- 假设某个RM本地事务失败。该RM自身驱动本地事务回滚，并且报告给TC。
- TM检测到了某个分支事务失败，向TC发起全局事务回滚。
- TC给每一个RM发送消息，通知它们全部回滚。
- TC将全局事务回滚的结果发送给TM，全局事务结束。
五、设计思想(重点)
Seata 的设计思路是将一个分布式事务可以理解成一个全局事务，下面挂了若干个分支事务，而一个分支事务是一个满足 ACID 的本地事务，因此我们可以操作分布式事务像操作本地事务一样。Seata 的事务提交方式跟 XA 协议的两段式提交在总体上来说基本是一致的，但XA 协议它依赖的是数据库层面来保障事务的一致性，也即是说 XA 的各个分支事务是在数据库层面上驱动的，由于 XA 的各个分支事务需要有 XA 的驱动程序，一方面会导致数据库与 XA 驱动耦合，另一方面它会导致各个分支的事务资源锁定周期长，所以性能较差。
Seata 在数据源做了一层代理层，所以我们使用 Seata 时，我们使用的数据源实际上用的是 Seata 自带的数据源代理 DataSourceProxy，Seata 在这层代理中加入了很多逻辑，主要是解析 SQL，把业务数据在更新前后的数据镜像组织成回滚日志，并将 undo log 日志插入 undo_log 表中，保证每条更新数据的业务 sql 都有对应的回滚日志存在。这样做的好处就是，本地事务执行完可以立即释放本地事务锁定的资源，然后向 TC 上报分支状态。当 TM 决议全局提交时，就不需要同步协调处理了，TC 会异步调度各个 RM 分支事务删除对应的 undo log 日志即可，这个步骤非常快速地可以完成；当 TM 决议全局回滚时，RM 收到 TC 发送的回滚请求，RM 通过 XID 找到对应的 undo log 回滚日志，然后执行回滚日志完成回滚操作。
六、其他模式
上面说的是seata的模式模式AT,seata也针对TCC做了适配兼容，支持TCC事务方案，原理前面已经介绍过，基本思路就是使用侵入业务上的补偿及事务管理器的协调来达到全局事务的一起提交及回滚。
七、总结
1)优点
- 阿里背书,社区活跃,github1.3w start。
- 相对2pc来说性能有较大提升,避免多个库锁定导致的性能急剧下降。
- 使用简单,学习成本低,对业务无入侵,对于AT模式来说,只需一个注解就可以实现分布式事务。
- 可通过HA-Cluster保证高可用。
- 灵活,拓展性高,配置,服务发现和注册,全局锁,可由用户自己实现。
2)缺点
- TC不支持集群部署,一旦TC宕机会导致无法处理分布式事务。
- Seata的引入全局锁会额外增加死锁的风险。
- 单机多数据源跨服务目前不支持。
一、事务与分布式事务
事务,在数据库中指的是操作数据库的最小单位,往大了看,事务是应用程序中一系列严密的操作，所有操作必须成功完成，否则在每个操作中所作的所有更改都会被撤消。
那为什么会有分布式事务呢?单机事务是通过将操作限制在一个会话内通过数据库本身的锁以及日志来实现ACID.因为引入了分布式架构,所以事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上.简单说就是多各数据库之间无法保证保证各自的操作同时成功或同时失败。
二、介绍
Seata:Simple Extensible Autonomous Transaction Architecture，简易可扩展的自治式分布式事务管理框架，其前身是fescar。阿里巴巴GTS的开源版实现，是一种分布式事务的解决方案。
三、架构
- Coordinator Core：最下面的模块是事务协调器核心代码，主要用来处理事务协调的逻辑，如是否 Commit、Rollback 等协调活动。
- Store：存储模块，用来将我们的数据持久化，防止重启或者宕机数据丢失。
- Discover：服务注册/发现模块，用于将 Server 地址暴露给 Client。
- Config：用来存储和查找服务端的配置。
- Lock：锁模块，用于给 Seata 提供全局锁的功能。
- Rpc：用于和其他端通信。
- HA-Cluster：高可用集群，目前还没开源。为 Seata 提供可靠的高可用功能。
四、工作流程
1)参与角色
Transaction Coordinator(TC)：管理全局的分支事务的状态，用于全局性事务的提交和回滚。
Transaction Manager(TM)：事务管理器，用于开启全局事务、提交或者回滚全局事务，是全局事务的开启者。
Resource Manager(RM)：资源管理器，用于分支事务上的资源管理，向TC注册分支事务，上报分支事务的状态，接受TC的命令来提交或者回滚分支事务。
2)流程
- TM向TC请求发起一个全局事务，TC返回一个代表这个全局事务的XID。
- XID在rpc中传播给每一个调用链中的服务。
- 每个RM拿到XID后向TC发起一个分支事务，TC返回一个代表这个分支事务的XID。
- RM完成本地分支的业务，提交本地分支，并且报告给TC。
- 全局事务调用链处理完毕，TM根据有无异常向TC发起全局事务的提交或者回滚。
- 假设某个RM本地事务失败。该RM自身驱动本地事务回滚，并且报告给TC。
- TM检测到了某个分支事务失败，向TC发起全局事务回滚。
- TC给每一个RM发送消息，通知它们全部回滚。
- TC将全局事务回滚的结果发送给TM，全局事务结束。
五、设计思想(重点)
Seata 的设计思路是将一个分布式事务可以理解成一个全局事务，下面挂了若干个分支事务，而一个分支事务是一个满足 ACID 的本地事务，因此我们可以操作分布式事务像操作本地事务一样。Seata 的事务提交方式跟 XA 协议的两段式提交在总体上来说基本是一致的，但XA 协议它依赖的是数据库层面来保障事务的一致性，也即是说 XA 的各个分支事务是在数据库层面上驱动的，由于 XA 的各个分支事务需要有 XA 的驱动程序，一方面会导致数据库与 XA 驱动耦合，另一方面它会导致各个分支的事务资源锁定周期长，所以性能较差。
Seata 在数据源做了一层代理层，所以我们使用 Seata 时，我们使用的数据源实际上用的是 Seata 自带的数据源代理 DataSourceProxy，Seata 在这层代理中加入了很多逻辑，主要是解析 SQL，把业务数据在更新前后的数据镜像组织成回滚日志，并将 undo log 日志插入 undo_log 表中，保证每条更新数据的业务 sql 都有对应的回滚日志存在。这样做的好处就是，本地事务执行完可以立即释放本地事务锁定的资源，然后向 TC 上报分支状态。当 TM 决议全局提交时，就不需要同步协调处理了，TC 会异步调度各个 RM 分支事务删除对应的 undo log 日志即可，这个步骤非常快速地可以完成；当 TM 决议全局回滚时，RM 收到 TC 发送的回滚请求，RM 通过 XID 找到对应的 undo log 回滚日志，然后执行回滚日志完成回滚操作。
六、其他模式
上面说的是seata的模式模式AT,seata也针对TCC做了适配兼容，支持TCC事务方案，原理前面已经介绍过，基本思路就是使用侵入业务上的补偿及事务管理器的协调来达到全局事务的一起提交及回滚。
七、总结
1)优点
- 阿里背书,社区活跃,github1.3w start。
- 相对2pc来说性能有较大提升,避免多个库锁定导致的性能急剧下降。
- 使用简单,学习成本低,对业务无入侵,对于AT模式来说,只需一个注解就可以实现分布式事务。
- 可通过HA-Cluster保证高可用。
- 灵活,拓展性高,配置,服务发现和注册,全局锁,可由用户自己实现。
2)缺点
- TC不支持集群部署,一旦TC宕机会导致无法处理分布式事务。
- Seata的引入全局锁会额外增加死锁的风险。
- 单机多数据源跨服务目前不支持。