事务处理

CAP

• C:数据一致性,数据需要同步才能一致
• A:可用性,系统是可以使用的
• P: 分区容错

注意: 只能满足两个,一般情况下是永远要满足P的

如果出现意外情况: 要保证数据一致,系统就不能用,如果想系统能用,就不能保证数据一致

分布式事务的官方解决方案

基于XA协议的两阶段提交

• 优点: 尽量保证了数据的强一致性,适合对数据一致性要求很高的关键领域
• 缺点: 牺牲了可用性,对性能影响较大,不适合高并发性能场景,如果分布式接口被调用,目前,NET界还没有解决方案

补偿事务TCC模式

• Try 预留业务资源/数据校验
• Confirm 确认执行业务操作,实际提交数据,不做任何业务检查,confirm必定成功,需保证幂等
• Cancel 取消执行业务操作,实际回滚数据,需保证幂等

Cancel可以恢复数据, 在Try的时候预留资源(相当于临时将之前的数据保存起来,如果Confirm,就删除预留资源,如果是Cancel,就恢复预留的资源)

• 优点: 它的性能比XA要高,因为各个服务之间调用没有被锁住,还有就是跨平台(和具体存储介质无关)
• 缺点: 数据不一致,预留资源,回滚这些业务逻辑的实现都需要程序员开发 (程序员需要写很多的补偿代码)

Seata

Seata支持两种模式

• AT模式
• TCC模式

AT模式

Seata AT模式是基于XA事务演进过来的

• Transaction Manager ™ 控制全局事务的边界,负责开启一个全局的事务,并最终发起全局提交或全局回滚的协议(发起投票)
• Transaction Coordinator (TC) 事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚
• Resource Manager(RM) 控制分支事务,负责分支注册,状态汇报,并接收事务协调的指令,驱动分支事务的提交和或回滚

1. 如果决议是回滚,RM收到协调器发来的回滚请求,通过XID和BranchID找到相应的回滚日志记录,通过回滚记录生成反向的更新SQL并执行
2. 如果决议是全局提交,此时分支事务已经完成提交,不需要同步协调处理(只需要异步清理回滚日志)

注意: 一阶段本地事务提交前必须要确保先拿到全局锁 拿不到全局锁,不能提交本地事务. 拿全局锁的尝试被限制在一定范围内,超出范围将放弃,并回滚本地事务,释放本地锁