前提为什么会出现分布式事务在以往的单体项目只有一个数据库而微服务中有多个数据库。因为本地事务管不了跨服务、跨数据库的操作。所以出现分布式事务解决之问题一.分布式事务基本概念1.参与者角色。2.二阶段提交2pc3.全局事务分支事务一参与者角色TC事务协调者。协调所有参与者管理全局事务提交或回滚TM事务发起者。发起全局事务并接受 TC 协调RM事务参与者。参与全局事务管理本地资源如本地数据库事务二二阶段提交2pc第一阶段TC 通知所有参与者准备提交参与者执行本地事务但不提交将准备结果通知 TC第二阶段如果所有参与者都成功TC 协调所有参与者提交事务如果存在参与者准备失败TC 协调所有参与者回滚事务三全局事务分支事务全局事务又称分布式事务包含所有分支事务分支事务又称本地事务是某个服务中的本地数据库事务二.常见的解决方案1.XA 协议2.TCC3.Seata AT 模式4.Saga一XA 协议XA 是数据库层面的分布式事务协议基于 2PC1.原理步骤一每个事务的参与者执行本地事务操作执行完之后通知事务的协调者但是不提交步骤二协调者汇总所有参与者状态全部成功通知所有参与者提交任意失败通知所有参与者回滚2.优点解决分布式事务的问题3.缺点存在事务挂起资源空耗性能低下二TCCTCC是将业务接口拆成三个接口。分别为Try、Confirm、Cancel1.三个阶段三个阶段对应三个接口Try尝试资源锁定。例如转账时冻结资金Confirm确认真正执行业务。例如解冻并完成转账Cancel取消逆向补偿。例如解冻资金2.两阶段准备阶段TC调用所有服务的Try接口提交阶段TC根据结果调用接口)全部成功调用 Confirm存在失败调用 Cancel3.优点能实现分布式事务没有事务挂起性能较好灵活度高4.缺点业务接口一拆三工作量和复杂度高。需要进行业务改造工作量大实现复杂三Seata AT 模式AT 是 Seata 创新的一种非侵入式分布式事务解决方案。1.原理前提在各个事务的数据库中建表 undo_log表第一阶段直接执行业务seata代理数据源DataSource)拦截sql执行提取sql执行前后的数据镜像将前后数据镜像转化成一条sql加入到当前本地事务执行提交插入到undo_log表中第二阶段TC 协调所有参与者全部成功直接删除undo_log。存在失败根据undo_log中的前后镜像生成逆向补偿 SQL执行回滚。四SagaSaga 是长事务解决方案。一阶段正向服务。二阶段补偿服务。三.seata的AT模式全局事务执行过程第一阶段全局事务开启与分支事务执行TM向TC开启全局事务TC生成全局唯一XID并返回。TM调用下游服务透传XID。下游RM获取XID向TC注册分支事务。RM执行SQL前生成前置镜像Before Image。RM执行SQL生成后置镜像After Image并将两者记录至undo_log。申请全局锁写隔离核心RM提交本地事务前向TC申请该行数据的全局锁。成功继续执行。失败重试超时则本地回滚并抛异常。获取全局锁后RM提交本地事务并释放本地锁但继续保持持有全局锁。第二阶段全局事务结束与锁释放TM根据执行情况向TC发起全局提交或回滚。全局提交TC通知RM清理undo_log释放全局锁。全局回滚TC通知RM利用undo_log反向补偿回滚完成后释放全局锁。核心逻辑本地事务提交前必须拿到全局锁且在全局事务彻底结束前不释放以此防止分布式环境下的脏写。四.seata的AT模式如何实现写隔离?获取本地锁分支事务开始时会先获取数据库的本地锁执行数据更新操作。申请全局锁在本地事务提交前必须向 TC 申请该数据记录的全局锁。等待与重试如果全局锁已被其他全局事务持有当前事务会释放本地锁并回滚然后通过循环不断重试尝试重新获取本地锁和全局锁直到超过预设的超时时间。提交与释放成功获取全局锁后本地事务才会提交并释放本地锁。全局锁会一直持有到整个全局事务完成二阶段结束后才释放。五.全局锁与本地锁的区别管理方全局锁由 Seata TC 管理本地锁由本地数据库管理。范围全局锁跨服务本地锁只在单个服务内。粒度全局锁锁数据行本地锁锁连接或行。释放时机全局锁等整个全局事务结束才释放本地锁本地事务一提交或回滚就释放。目的全局锁防止全局事务之间脏写本地锁保证本地事务 ACID。核心区别全局锁管分布式写隔离本地锁管单机事务一致性。六.缓存与数据库不同步如何解决Cache Aside最常用读先读缓存未命中读数据库再回填缓存并设过期时间。写先更新数据库再删除缓存。不要更新缓存直接删避免并发写覆盖。延迟双删更新数据库后删一次缓存延迟几百毫秒再删一次。用来应对并发读回填旧数据、主从延迟等问题。订阅 binlog MQ高可靠用 Canal 等监听 MySQL binlog发消息到 MQ消费者再删缓存。业务解耦失败可重试保证最终一致。分布式锁 / 版本号同一 key 的读写串行化或缓存带版本号做 CAS。适合强一致场景但性能差。过期时间兜底所有缓存都设 TTL即使短期不一致最终也会恢复。