java分布式事务

你们的分布式事务怎么处理的?[面试9.0]

2PC事务方案
TCC方案(也是基于2PC)
可靠消息最终一致性方案

2PC事务方案?[面试7.5]

2PC两阶段分布式事务提交协议
两阶段提交又称2PC,2PC是一个非常经典的强一致,中心化的原子提交协议

第一阶段: 投票阶段
事务询问: 协调者向所有参与者发送事务预处理请求,并等待响应
执行事务: 各个参与者执行本地事务操作,写Undo和Redo日志,此时事务并未提交
反馈结果: 各参与者向协调者反馈yes或no

第二阶段: 提交事务
所有参与者都返回Yes后,协调者向所有参与者发起commit请求

第二阶段: 中断事务
若有一个参与者反馈的ack为no->那么协调者向所有参与者发出RollBack请求,参与者接收到RollBack请求后,会回滚本地事务(利用第一阶段写的Undo日志回滚),回滚完成后向协调者反馈ack信息

2PC的缺点:
同步阻塞: 必须等待所有参与者反馈ack,是同步阻塞的,性能差
单节点故障: 协调者可能宕机,在第二阶段出问题的话,参与者一直会锁定事务资源,无法完成事务
数据不一致: 只有协调者设置了超时而参与者没设置超时,在第二阶段时由于网络原因,可能有参与者没有收到commit请求,一直不提交事务,会导致数据读取不一致的问题,资源也得不到释放

3PC相对于2PC有哪些区别:
3PC是CanCommit,PreCommit,DoCommit的设计
CanCommit阶段: 协调者发送给所有参与者CanCommit请求,参与者尝试获取数据库锁,若可以获取,就返回Yes
PreCommit和DoCommit阶段: PreCommit和DoCommit阶段和2PC相似,不同在于PreCommit的参与者多加了一个超时
3PC多设置了一个CanCommit阶段来获取数据库锁,保证了各参与者的状态是一致的,并且获取锁的时间一定比执行事务时间短,所以减少了同步阻塞的时间
3PC的参与者也设置了超时,当协调者挂了时能根据超时提交事务并释放资源,解决了单节点故障导致参与者资源无法释放的问题
3PC依然没有解决数据不一致的问题

分布式事务的TCC方案怎么理解?[面试7.5]

TCC分布式事务处理方案

TCC的全称是:Try,Confirm,Cancel(也是3种状态,try失败可以指定事务状态)
TCC事务管理框架:TCC-transaction框架

TCC事务分为两个阶段:
第一阶段: Try
第二阶段: Confirm,Cancel

实现原理:
1.事务管理器(协调者)反射业务系统方法执行Try开启业务事务,并记录事务日志到数据库(用于跨服务的重新load回事务对象用)和当前线程(为了之后代码能方便取出,比如在添加参与者时)
2.业务系统开启时会出现两种情况: 要么业务系统都成功了,要么至少一个业务系统失败了,TCC中是通过AOP中的环绕Try Catch来判断是否有一个Try出现了问题
若有失败的->事务管理器会向所有参与者发起Cancel
若都成功了->事务管理器会向所有参与者发起Confirm
3.若Confirm请求或Cancel请求失败了,TCC有一个任务调度恢复器会进行恢复处理,相当于协调者重放,重试,重试次数可以指定,并且当重试次数用完后需要人工干预(保证了数据一致性)

减少了同步阻塞问题: Try阶段进行资源检查和资源锁定,不像2PC那样需要等待所有协调者执行事务完毕
解决了单点故障问题:
协调者(事务管理器)和参与者都设置了超时,最终能释放资源
TCC事务管理器是多点的,TCC事务会记录分布式事务的活动日志,该日志保存了分布式事务运行的各个阶段和状态,当挂掉的节点重启时,TCC会读取之前保存的阶段和状态并执行事务的Commit或Cancel

业务举例:
提现的例子:
用户提交在产品服务提交100元提现申请,产品服务插入提现申请记录,并标记状态为待提现
这时已经由事务管理器开启了一个事务,产品服务继续执行代码调用银行存管服务,首先将用户可用余额中100元作为提现冻结金额,然后对银行系统发起提现申请,等待提现申请同步响应,这里有两种情况: 1.提现申请成功,2.提现申请失败
若提现申请失败->事务管理器会让银行存管系统执行Cancel方法,即将用户的提现冻结金额还原
若提现申请成功->继续调用银行系统提现确认接口等待提现确认异步通知,若收到异步通知,事务管理器会让银行存管系统执行Confirm方法