场景
1、单体服务多数据源,数据分部在不同的数据库实例,同时操作不同的数据库连接进行数据操作,跨数据库实例产生分布式事务。
2、多服务访问同一个数据库,不同服务各自持有数据库连接实例,跨JVM进程,产生分布式事务。
3、微服务场景下,多个服务拥有各自的数据库实例,通过服务间远程调用,操作数据库完成业务场景,产生分布式事务。
解决方案
2PC(两阶段提交)
阶段一:
- 事务协调者向事务参与者发起prepare请求
- 事务参与者返回准备完毕信息
阶段二:
- 事务协调者向事务参与者发起commit请求
- 事务参与者各自在本地事务提交事务,返回提交结果,失败则回滚所有事务。
3PC(三阶段提交)
2PC的升级版,把2PC的第一阶段拆分成两个阶段。整个过程:
1、CanCommit阶段
协调者向参与者发送Cancommit请求,询问是否可以提交事务,并等待参与者反馈yes或no。
2、PreCommit阶段
协调者根据所有参与者的反馈,yes则向所有参与者发送PerCommit请求,进入准备阶段。
参与者接收到请求在各自事务进行预提交,并返回预提交成功yes或者失败no。
3、DoCommit阶段
协调者向参与者发起DoCommit请求。
参与者各自提交本地事务,并返回执行结果。
在阶段二任何一个协调者返回no或者响应超时,协调者会发送abort请求,所有参与者进行事务回滚。
TCC(事务补偿)
TCC(try-confirm-cancel)是业务代码层面的两阶段提交,具有较强的侵入性。
第一阶段:
try (尝试):对业务资源检测及加锁预留资源。
第二阶段:
confirm(确认):执行提交业务逻辑。
cancel(取消):执行取消业务逻辑。
版权声明:本文为qq_36700462原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。