分布式事务理不清？先来了解两阶段提交吧

 

XA规范：

定义了事务协调者与数据库之间的接口规范。由数据库厂商实现。

分布式事务

会涉及到多个数据库(服务)的事务。

 

2PC两阶段提交

第一个阶段：准备（投票），并不commit

第二个阶段：提交执行（同意）

就像彩排失败就取消演出，彩排成功就进行演出。

缺点：

1.单点故障。事务协调者一定不能挂，否则事务失效。即使使用seata也会有这问题

2.阻塞资源。第一阶段不释放资源

3.数据不一致。第二阶段部分事务未成功commit

为什么很多公司还在使用？

以上3个问题出现的概率低，参考鸵鸟算法

 

两阶段的实现——TCC，适用于业务比较简单的场景

Try:执行业务操作/空操作

confirm:空操作/业务操作

cancel:取消操作（逆操作）

confirm与cancel只能执行一个，都属于第二阶段

 

场景举例

比如转账，张三减100，李四加100

正常情况：

Try阶段：张三update减100，commit，李四update加100，commit

Confirm阶段：张三空操作，李四空操作

异常情况：

Try阶段：张三update减100之后服务异常，commit，李四update加100，commit

cancel阶段：张三update加100，commit，李四update减100，commit

但是从里斯角度来说，会给用户造成困惑

正常情况(转账)改进：

Try阶段：张三update减100，commit，李四空操作

Confirm阶段：张三空操作，李四update加100，commit

进阶：

业务复杂，转账同事还要更新订单，扣除转账次数等，在逆操作阶段工作量会很复杂

解决：

lcn模式，或用seata的AT模式

TCC适用于：

1.业务特别简单

2.支持事务的DB和不适合事务的DB，一起操作的时候

 

AT模式：

第一阶段：释放资源前，记录了SQL images，增加了存储量

第二阶段：删除SQL  images，回滚则恢复SQL images

 

LCN模式：

第一阶段：release(){#collection.close()}

第二阶段：{#collection.commit()   或  rollback()}