本文主要是介绍Seataf分布式事务的使用，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一、事务的四大特征（面试题）
- 原子性：一个事务是不可分割的，要不都做，要不都不做
- 一致性：事务必须是使数据库从一个一致性变成另一个一致性状态
- 隔离性：一个事务的执行不被其他事务干扰，分为四个等级：读未提交、读已提交、可重复读、串行化
- 持久性：事务一旦提交，对数据库的数据改变是永久性的
二、事务的实现
2.1、本地事务
本地事务是在大多数情况下应用只需要操作单一的数据库
2.2 分布式事务
分布式事务是为了保证不同资源服务器的数据一致性
三、常见的分布式事务解决方案
- XA两段提交(低效率)-分布式事务解决方案
- TCC三段提交(2段,高效率[不推荐(补偿代码)])
- 本地消息(MQ+Table) 最终一致性
- 事务消息(RocketMQ) (唯一不同的就是将本地消息表存在了MQ内部)
- Seata(alibaba) （推荐）
redo log 持久性
redo一般用于恢复已确认但未写入数据库的数据，记录的是数据修改后的值。
undo log 一致性，原子性
undo一般用于事务的取消与回滚，记录的是数据修改前的值；
四、两阶段提交与三阶段提交的区别（面试题）
两阶段中有预提交阶段和提交阶段
三阶段中有准备阶段（CanCommit）、预提交阶段（PreCommit）、提交阶段（DoCommit）
三阶段与二阶段相比，降低了阻塞时长
两个阶段都不能保证数据绝对的一致性，可以人工干预通过脚本自动补偿差异的信息
五、TCC
TCC的执行流程
- 第一阶段，Try，业务系统做检测并且预留资源
- 第二阶段，根据第一阶段结果决定执行confirm还是cancel
connfirm：执行真正的业务
cancel：释放Try阶段的预留资源
优点：性能提升，数据最终一致性，可靠性
缺点：业务耦合度较高，提高开发成本
六、saga
Saga事务核心就是将长事务拆分为多个本地短事务并依次正常提交
saga的恢复策略
（1）向后恢复（backward recovery）
当事务执行失败后，补偿所有已完成的事务，如
（2）向前恢复（forwward recovery）
执行不通过的事务，会尝试重试事务
七、Seate分布式事务
Seate的三大角色
- TC（Transaction Coordinator）事务协调者：维护全局和分支事务状态，驱动全局事务提交或回滚
- TM（Transaction Manager）事务管理器：定义全局事务范围：开始、提交或回滚全局事务
- RM（Resource Manager）资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
TC 为单独部署的 Server 服务端，TM 和 RM 为嵌入到应用中的 Client 客户端
有三个主要的数据库表
global_table 就是存储的全局事务信息
branch_table 短事务相关信息
lock_table 当前锁的行信息
这篇关于Seataf分布式事务的使用的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
