一.分布式事务基本概念分布式事务解决的是跨服务、跨数据库操作的一致性问题在CAP理论下通常需要在强一致性和高可用性之间做权衡BASE理论则强调的是基本可用、软状态和最终一致性。事务参与角色事务协调者协调所有参与者管理全局事务事务发起者发起全局事务接收TC协调事务参与者参与全局事务。二.分布式事务解决方案1. XA协议数据库协议实现原理事务协调者先让所有参与者各自本地操作根据所有参与者的操作结果再统一提交或者回滚。么个事务参与者先执行本地事务执行完成后不提交通知事务协调者事务协调者汇总事务执行状态根据结果进行处理所有参与者执行成功事务协调者会通知所有参与者一起提交事务。如果有一个参与者没有执行成功协调者会通知所有参与者回滚事务。特点强一致性但是回阻塞性能低适用于金融核心等并发场景。2. TCCTry-Confirm-Cancel对应有三个接口Try 预留或者锁定资源Confirm 确认执行Cancel 释放资源并你想补偿分为两阶段提交准备阶段TC调用所有服务的Try接口提交阶段TC根据结果如果所有成功则调用所有服务的Confirm接口如果存在失败则调用所有服务的Cancel接口特点高性能、无数据库长时间的事务等待业务侵入强3. Seata AT模式基于数据源代理拦截 SQL自动生成 undo_log按全局事务状态提交或回滚AT 自动事务处理Seata 创新的一种非侵入式的分布式事务解决方案实现方式在各个事务的数据库中建表 undo_log表第一阶段 直接执行业务seata代理数据源DataSource)拦截sql执行提取sql执行前后的数据镜像将前后数据镜像转化成一条sql加入到当前本地事务执行提交插入到undo_log表中第二阶段如果所有参与者都处理成功TC 协调所有参与者直接删除undo_log记录如果存在参与者处理失败TC协调所有的参与者回滚参与者从undo_log表中提取前后镜像计算得到逆向补偿sql执行sql实现补偿特点无侵入、易操作适合微服务下关系型数据库场景4. Saga拆成多个本地事务有一个事务失败失败时执行补偿。特点适合长事务无长时间锁但补偿逻辑复杂三.Seata AT 模式全局事务执行过程Seata AT 模式依赖三个角色前面提到过TC事务协调者维护全局事务状态驱动提交或回滚TM事务发起者开启全局事务决定提交或回滚RM事务参与者管理分支事务生成 undo_log执行本地事务和二阶段操作执行流程如下TM 开启全局事务TC 生成 XID。XID 传递到下游服务各服务的 RM 识别到 XID 后注册分支事务。一阶段执行本地事务RM 拦截 SQL查询前镜像执行业务 SQL查询后镜像生成 undo_log将业务数据和 undo_log 在同一个本地事务中提交。提交前获取全局锁RM 在本地事务提交前向 TC 申请全局锁获取成功后提交本地事务释放本地数据库锁获取失败则回滚本地事务并重试或超时放弃。二阶段提交若全局事务提交TC 通知各 RM 异步删除 undo_log过程很快。二阶段回滚若全局事务回滚TC 通知 RM 根据 undo_log 的前镜像生成反向 SQL回滚前会校验当前数据是否与后镜像一致一致则回滚不一致则说明存在外部脏写可能需要人工处理。四.Seata AT 模式如何实现写隔离AT 模式的写隔离不是靠长时间持有数据库锁实现的而是通过全局锁和本地锁配合完成的。当两个全局事务修改同一行数据时事务 A 先执行获取数据库行锁更新数据生成前后镜像。事务 A 在本地事务提交前向 TC 申请该行数据的全局锁。申请成功后事务 A 提交本地事务释放数据库行锁但继续持有全局锁。事务 B 随后执行也能获取数据库行锁并更新数据但在提交前申请全局锁时会发现该行已被事务 A 持有。事务 B 只能等待全局锁释放如果事务 A 全局提交B 继续提交如果事务 A 全局回滚A 会根据 undo_log 反向补偿B 最终超时或等待后重新执行。这样就避免了“事务 A 已提交本地事务但全局事务尚未结束”时事务 B 基于中间状态数据继续修改造成的脏写。五.全局锁与本地锁的区别本地锁数据库自身的行锁由数据库管理在本地事务执行期间持有事务提交或回滚后立即释放只能保证单个数据库本地事务的隔离性。全局锁Seata TC 维护的逻辑锁由 RM 在本地事务提交前申请持有到全局事务二阶段结束才释放用于保证跨全局事务的写隔离。六.缓存与数据库不同步如何解决缓存与数据库不一致的根本原因是两者无法原子更新且存在并发读写、网络延迟和缓存失效时序问题。通常以数据库为唯一可信数据源追求最终一致性。常用方案Cache-Aside 旁路缓存读先查缓存未命中再查数据库并回填缓存。写先更新数据库再删除缓存。这是最常用方案实现简单但存在短暂不一致窗口。延迟双删更新数据库后删除缓存再延迟一段时间再次删除缓存用于清除并发读请求回填的旧数据。延迟时间需大于读库回填缓存的耗时及可能的主从同步延迟。消息队列补偿数据库更新成功后发送 MQ 消息由消费者异步删除缓存。支持重试和死信兜底适合分布式系统但增加了链路复杂度。Binlog 监听通过 Canal 等工具订阅 MySQL Binlog解析数据变更后异步删除或更新缓存。业务代码侵入小适合微服务架构和数据异构同步。兜底策略给缓存设置合理 TTL即使删除失败也能自动过期刷新核心强一致场景可减少缓存依赖或直接读主库。工程实践中“先更新数据库再删除缓存 合理 TTL MQ/Binlog 兜底”是较常见的组合如果一致性要求很高再叠加延迟双删或版本号控制。