1. 分布式事务的基本概念定义分布式事务是指保证多个原子服务的操作要么全部成功、要么全部失败从而确保数据一致性的机制。角色1.事务发起者TM发起全局事务接收TC协调 2.事务协调者TC协调所有事务参与者管理全局事务 3.事务参与者RM参与全局事务全局事务又称分布式事务它包含了所有的分支事务分支事务类似于单体项目的事务是指每个服务自己专属的本地事务2. 分布式事务的常见解决方案2.1 XA协议XA协议提交是最经典的分布式事务协议由协调者和多个参与者组成。整个过程分为两个阶段准备阶段协调者向所有参与者发送准备请求参与者执行完本地事务后但不提交等待协调者进行结果汇总等待所有参与者回复 [可以提交] 则继续下一阶段。提交阶段如果所有参与者都返回 [可以提交] 协调者广播提交指令各参与者正式提交本地事务如果任一参与者返回 [需要回滚] 协调者广播回滚指令各参与者回滚事务。XA协议的优点是原理简单、可直接实现分布式事务缺点是存在事务挂起、资源空耗性能低下等问题2.2 TCC 补偿事务TCCTry-Confirm-Cancel是一种补偿型事务将每个业务接口都拆分为三个接口Try尝试执行业务完成资源预留和业务检查但不真正提交。Confirm确认执行业务使用 Try 阶段预留的资源完成真正的业务操作。Cancel取消执行业务释放 Try 阶段预留的资源。TCC 的优点是性能较好(没有事务挂起)灵活度高适合并发量大的场景缺点是每个业务都需要实现 Try、Confirm、Cancel 三个接口开发成本较高。2.3 Seata AT 模式主流Seata 是阿里巴巴开源的一套分布式事务解决方案目的是在微服务架构中能提供简单好用且高性能的分布式事务服务。其 AT 模式基于2PC提交思想通过全局锁和 undo log 机制对业务代码侵入性极低是目前业界应用最广泛的方案之一。3. Seata AT 模式的全局事务执行过程Seata AT 模式的核心角色包括事务协调者TC、事务管理器TM和资源管理器RM。全局事务的执行过程分为两个阶段3.1 第一阶段业务 SQL 执行与 undo_log 记录TM 向 TC 发起全局事务开启请求TC 生成全局事务 IDXID并通过调用链传递到各个微服务。RM 拦截业务 SQL生成执行前的数据快照和执行后的数据快照并将快照信息写入 undo_ log 表。RM 执行本地业务 SQL提交本地事务同时向 TC 注册分支事务并上报执行结果。第一阶段结束时本地事务已经提交数据对外可见因此 AT 模式在提交阶段没有长时间的锁持有性能较好。3.2 第二阶段全局提交或全局回滚TM 根据业务执行结果向 TC 发起全局提交或全局回滚请求。全局提交TC 通知各 RM 异步删除所有undo_log表数据释放全局锁完成提交。全局回滚TC 通知各 RM 根据 undo_log 表中的SQL执行前的数据快照生成反向 SQL将数据恢复为执行前的状态然后删除 undo_log表数据释放全局锁。4. Seata AT 模式如何实现写隔离写隔离是保证并发事务之间数据不会互相覆盖。Seata AT 模式通过全局锁机制实现写隔离具体过程如下在本地事务提交前RM 会向 TC 申请针对目标数据行的全局锁。全局锁的粒度是行级锁信息记录在 TC 的锁表中。如果全局锁申请成功RM 才允许提交本地事务如果申请失败说明其他全局事务正在操作同一行数据RM 会等待重试直到获取锁或超时。由于本地事务在获取全局锁之后才提交因此其他全局事务无法同时修改同一行数据从而实现写隔离。5. 全局锁与本地锁的区别本地锁解决的是单个数据库内并发事务的隔离问题而全局锁解决的是跨服务、跨数据库的分布式并发写冲突问题。AT 模式在本地事务提交前先获取全局锁再依赖数据库本地锁保证本地事务内部的隔离性。6. 缓存与数据库不同步如何解决缓存与数据库不同步是分布式系统中的经典问题常见于使用 Redis 等缓存加速读操作、以数据库为最终数据源的场景。方案一Cache Aside Pattern (旁路缓存模式) 重试机制策略先更新数据库再删除缓存。兜底如果删除缓存失败怎么办消息队列重试将删除失败的消息发入MQ后台消费者不断重试删除。Canal 订阅 Binlog 业务代码只更新DB利用阿里 Canal 伪装成 MySQL 从节点订阅 Binlog解析出变更的数据异步去删除/更新 Redis。完全解耦业务代码。方案二延迟双删策略先删除缓存 - 更新数据库 - 休眠N毫秒 - 再次删除缓存。原理第二次删除是为了抹平在“更新DB”期间其他读请求将旧数据重新加载到缓存中产生的脏数据。缺点休眠时间难以评估需大于读业务耗时且降低了系统吞吐量。方案三设置合理的过期时间无论使用哪种策略都必须给缓存设置合理的 TTL过期时间。即使上述所有删除缓存的动作都失败了等 TTL 到期后缓存自动失效下一次读请求会重新从 DB 加载最新数据保证最终一致性。7. 总结分布式事务是微服务架构下保证跨服务数据一致性的核心难题。从 2PC到 TCC再到 Seata AT 模式每种方案都在一致性、可用性和性能之间做了不同的权衡。Seata AT 模式通过全局锁和 undo_log 实现了对业务低侵入的最终一致方案是当前实践中的主流选择。同时缓存与数据库的一致性问题也需要结合具体业务场景选择合适的更新策略和补偿机制才能在高并发下保证数据的正确性。 1. 分布式事务的基本概念定义分布式事务是指保证多个原子服务的操作要么全部成功、要么全部失败从而确保数据一致性的机制。角色1.事务发起者TM发起全局事务接收TC协调 2.事务协调者TC协调所有事务参与者管理全局事务 3.事务参与者RM参与全局事务全局事务又称分布式事务它包含了所有的分支事务分支事务类似于单体项目的事务是指每个服务自己专属的本地事务2. 分布式事务的常见解决方案2.1 XA协议XA协议提交是最经典的分布式事务协议由协调者和多个参与者组成。整个过程分为两个阶段准备阶段协调者向所有参与者发送准备请求参与者执行完本地事务后但不提交等待协调者进行结果汇总等待所有参与者回复 [可以提交] 则继续下一阶段。提交阶段如果所有参与者都返回 [可以提交] 协调者广播提交指令各参与者正式提交本地事务如果任一参与者返回 [需要回滚] 协调者广播回滚指令各参与者回滚事务。XA协议的优点是原理简单、可直接实现分布式事务缺点是存在事务挂起、资源空耗性能低下等问题2.2 TCC 补偿事务TCCTry-Confirm-Cancel是一种补偿型事务将每个业务接口都拆分为三个接口Try尝试执行业务完成资源预留和业务检查但不真正提交。Confirm确认执行业务使用 Try 阶段预留的资源完成真正的业务操作。Cancel取消执行业务释放 Try 阶段预留的资源。TCC 的优点是性能较好(没有事务挂起)灵活度高适合并发量大的场景缺点是每个业务都需要实现 Try、Confirm、Cancel 三个接口开发成本较高。2.3 Seata AT 模式主流Seata 是阿里巴巴开源的一套分布式事务解决方案目的是在微服务架构中能提供简单好用且高性能的分布式事务服务。其 AT 模式基于2PC提交思想通过全局锁和 undo log 机制对业务代码侵入性极低是目前业界应用最广泛的方案之一。3. Seata AT 模式的全局事务执行过程Seata AT 模式的核心角色包括事务协调者TC、事务管理器TM和资源管理器RM。全局事务的执行过程分为两个阶段3.1 第一阶段业务 SQL 执行与 undo_log 记录TM 向 TC 发起全局事务开启请求TC 生成全局事务 IDXID并通过调用链传递到各个微服务。RM 拦截业务 SQL生成执行前的数据快照和执行后的数据快照并将快照信息写入 undo_ log 表。RM 执行本地业务 SQL提交本地事务同时向 TC 注册分支事务并上报执行结果。第一阶段结束时本地事务已经提交数据对外可见因此 AT 模式在提交阶段没有长时间的锁持有性能较好。3.2 第二阶段全局提交或全局回滚TM 根据业务执行结果向 TC 发起全局提交或全局回滚请求。全局提交TC 通知各 RM 异步删除所有undo_log表数据释放全局锁完成提交。全局回滚TC 通知各 RM 根据 undo_log 表中的SQL执行前的数据快照生成反向 SQL将数据恢复为执行前的状态然后删除 undo_log表数据释放全局锁。4. Seata AT 模式如何实现写隔离写隔离是保证并发事务之间数据不会互相覆盖。Seata AT 模式通过全局锁机制实现写隔离具体过程如下在本地事务提交前RM 会向 TC 申请针对目标数据行的全局锁。全局锁的粒度是行级锁信息记录在 TC 的锁表中。如果全局锁申请成功RM 才允许提交本地事务如果申请失败说明其他全局事务正在操作同一行数据RM 会等待重试直到获取锁或超时。由于本地事务在获取全局锁之后才提交因此其他全局事务无法同时修改同一行数据从而实现写隔离。5. 全局锁与本地锁的区别本地锁解决的是单个数据库内并发事务的隔离问题而全局锁解决的是跨服务、跨数据库的分布式并发写冲突问题。AT 模式在本地事务提交前先获取全局锁再依赖数据库本地锁保证本地事务内部的隔离性。6. 缓存与数据库不同步如何解决缓存与数据库不同步是分布式系统中的经典问题常见于使用 Redis 等缓存加速读操作、以数据库为最终数据源的场景。方案一Cache Aside Pattern (旁路缓存模式) 重试机制策略先更新数据库再删除缓存。兜底如果删除缓存失败怎么办消息队列重试将删除失败的消息发入MQ后台消费者不断重试删除。Canal 订阅 Binlog 业务代码只更新DB利用阿里 Canal 伪装成 MySQL 从节点订阅 Binlog解析出变更的数据异步去删除/更新 Redis。完全解耦业务代码。方案二延迟双删策略先删除缓存 - 更新数据库 - 休眠N毫秒 - 再次删除缓存。原理第二次删除是为了抹平在“更新DB”期间其他读请求将旧数据重新加载到缓存中产生的脏数据。缺点休眠时间难以评估需大于读业务耗时且降低了系统吞吐量。方案三设置合理的过期时间无论使用哪种策略都必须给缓存设置合理的 TTL过期时间。即使上述所有删除缓存的动作都失败了等 TTL 到期后缓存自动失效下一次读请求会重新从 DB 加载最新数据保证最终一致性。7. 总结分布式事务是微服务架构下保证跨服务数据一致性的核心难题。从 2PC到 TCC再到 Seata AT 模式每种方案都在一致性、可用性和性能之间做了不同的权衡。Seata AT 模式通过全局锁和 undo_log 实现了对业务低侵入的最终一致方案是当前实践中的主流选择。同时缓存与数据库的一致性问题也需要结合具体业务场景选择合适的更新策略和补偿机制才能在高并发下保证数据的正确性。