持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第16天，点击查看活动详情
分布式事务
分布式系统中，通常一个业务可能涉及多张表，多个库；本地事务已经没办法满足分布式架构下的事务问题，因此引入分布式事务的方式来解决相关问题；
一般常见的分布式事务的解决方案：
-
二阶段提交（2PC）
分布式事务通常会有一个事务管理者来统一管理事务是否提交，是否执行等操作；
- 阶段一：事务执行
- 事务管理者向集群中的服务发起事务执行的请求，参与的服务执行事务，将实行的结果返回给管理者，成功或失败，将事务执行记录写入Undo日志，Redu日志；中间发生失败则统一回滚；
- 阶段二：事务提交
-
事务管理器向参与事务的服务发起commit提交事务请求处理，参与者提交事务释放当前占用的资源，完成事务提交后向管理者发送ACK确认，管理者收到确认则事务提交完成；
-
这种方式逻辑简单易于操作开发
但是在二段提交过程中会阻塞资源，在提交过程中当前参与者会占用公共资源，若此时有其他业务也要处理这个资源，会造成阻塞等待；
依赖于事务管理器，如果阶段二在提交事务请求时，管理器挂了，那么占用着资源的参与者将会一直锁定资源；可能会在数据不一致
- 阶段一：事务执行
-
三阶段提交（3PC）
在二段式的基础上衍生出CanCommit、PreCommit、DoCommit三个阶段的概念
-
CanCommit阶段
协调者向参与者发送CanCommit请求，然后等待参与者的响应，参与者认为可以参与事务执行，则返回yes否则返回 NO
-
PreCommit提交
管理者根据参与者的响应果来决定是否执行，PreCommit；
yes的话，则进行事务的预提交，把响应的日志文件写入undolog,返回预提交的结果到管理者；
no的话，则是只要有一个参与者额响应是No则全部事务都会被中断取消
-
DoCommit阶段
在这一阶段才是真正的提交事务操作
根据上一阶段的响应结果，正式提交或者中断
-
XA规范
XA定义了三个角色
- AP:业务层，就是当前操作属于哪个事务
- TM:事务管理器 接收事务请求控制事务的执行和提交
- RM:资源管理器，也就是事务的落地者；
基于两段式提交的方式，引入事务管理者（TM）用来统一管理各个机器的事务配置，跨数据库跨进程；
补偿模式TCC
包含三种操作
Try:调用try接口，完成业务一致性检查，预留必业务资源；
Confirm: 对业务做提交操作。不做业务检查，只是用ry预留的业务资源
Cancel：业务执行错误，取消执行，释放Try预留业务资源。 由主业务方发起并完成业务活动,业务活动管理器可以变成多点， 引入集群。 同步阻塞：引入超时机制，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻 辑形式，粒度变小。 数据一致性，有了补偿机制之后，由业务活动管理器控制一致性。
