分布式事务学习笔记分布式事务的概念事务概念事务是一组数据库操作要么全部成功要么全部失败不能只做一半。事务的概念至少是两条数据同时发生改变可以是在一张表改变两条数据也可以是两张表各同时改变一条状态比如A 扣钱和 B 加钱必须一起成功不能只扣不加或者用户数据库注册用户同时另外一张表新增一条状态事务有四个特性ACID原子性要么全做要么全不做、一致性数据从一个正确状态变到另一个正确状态、隔离性并发事务互相不干扰、持久性提交了就丢不了。以前单体项目所有操作都在一个库里一个 Transactional 就能保证这些这叫本地事务。同时Transactional 类似于分布式事务里面的GlobalTransactiona现在项目拆成了多个微服务各管各的数据库。比如下单要扣用户余额用户库 插订单记录订单库这就变成了分布式事务本地事务只能管住自己那个库扣钱成功了下单失败了数据就乱了。分布式事务要解决的就是跨服务、跨库的操作怎么保证要么都成功要么都失败。重点的三个角色TC事务协调者单独部署的 Seata Server统一指挥大家提交还是回滚TM事务发起者发起全局事务的入口服务RM事务参与者各个真正干活、操作数据库的服务还有两个概念全局事务整个大事务包含所有服务的操作分支事务每个服务自己的本地事务是全局事务的一部分解决方案有哪些今天了解了四种先简单记一下区别XA2PC两阶段提交第一阶段大家都执行但不提交第二阶段统一提交或回滚。缺点是资源一直被占着性能差。TCC每个接口拆成 Try/Confirm/Cancel 三个写。性能好但代码侵入太大改造麻烦。Seata AT我们项目用的这个。只加一个GlobalTransactional注解就行侵入最小。Saga长事务用每个服务直接提交失败了调补偿接口倒着改回去。不保证隔离性。Seata AT 模式全局事务的执行过程今天重点学的这个流程大概是入口方法上有GlobalTransactional调用时 TM 向 TC 开启全局事务拿到一个 XID全局事务 id。下游服务被 Feign 调用时 XID 会跟着请求传过去大家就知道自己在同一个全局事务里。每个服务RM向 TC 注册自己的分支事务。一阶段Seata 代理了数据源拦截 SQL把数据修改前和修改后的镜像记下来和业务 SQL 在同一个本地事务里提交到 undo_log 表。提交完本地锁就释放了。二阶段都成功TC 通知大家把 undo_log 删掉就完事很快。有失败TC 通知回滚RM 从 undo_log 取之前存的前镜像生成反向 SQL 把数据改回去。我自己在日志里看到过Begin new global transaction和rollback status: Rollbacked数据库里的数据确实恢复原样了。AT 模式怎么实现写隔离全局锁和本地锁的区别为什么要隔离两个全局事务同时改同一行如果不管一个改了提交了另一个失败回滚时拿前镜像把数据改回去就把前者的修改覆盖了脏写。AT 的做法分支事务在本地提交前要先向 TC 申请这行数据的全局锁拿到才能提交。全局锁一直持有到二阶段结束才释放这样别的事务想改同一行就得排队。两种锁的区别我自己的理解本地锁数据库自己的行锁只管一个库内部一阶段提交后就释放。全局锁Seata 在 TC 那边维护的按 表名主键 标识数据库不知道它二阶段结束才释放管的是跨服务的并发安全。简单说就是本地锁早放是为了性能全局锁兜底是为了不出错。缓存和数据库不同步怎么解决更新数据时数据库改了、缓存还是旧的用户就会读到脏数据。常见办法先更新数据库再删缓存最常用。注意是删缓存不是更新缓存删掉等下次读的时候重新查库回写。延迟双删更新前删一次更新完隔一会再删一次防止中间有请求把旧数据又写回缓存。监听 binlog用 Canal 监听数据库变更发 MQ 异步删缓存可靠但要多维护中间件。给缓存设过期时间兜底就算删除失败脏数据过一会也会自动失效。一般项目里更新库 删缓存 过期时间组合就够用了。参考Seata 官方文档、笔记内容