凡科建站是什么,电商网站适合做响应式布局吗,wordpress怎么创建菜单,wordpress社交风格模板1. 引言#xff1a;ACID 的崩塌与 BASE 的崛起在微服务架构下#xff0c;随着业务的拆分#xff0c;数据库也随之分库分表。传统的单机事务#xff08;ACID#xff09;在跨库、跨服务场景下失效。为了保证数据的一致性#xff0c;我们引入了分布式事务。常见的分布式事务…1. 引言ACID 的崩塌与 BASE 的崛起在微服务架构下随着业务的拆分数据库也随之分库分表。传统的单机事务ACID在跨库、跨服务场景下失效。为了保证数据的一致性我们引入了分布式事务。常见的分布式事务解决方案包括XA (2PC): 强一致性但阻塞严重性能差。TCC: 性能好但业务侵入性极强需要写 Try-Confirm-Cancel 三段逻辑。Saga: 长事务解决方案基于状态机适合复杂业务流程。Seata AT: 基于 2PC 的改进版无侵入自动生成 SQL性能与一致性的折中方案。2. Seata AT 模式原理改进版的 2PCSeata AT 模式的核心理念是将两阶段提交的机制下沉到数据库层面的代理中对业务代码无侵入。2.1 两个阶段概览一阶段Phase 1解析业务 SQL。查询操作前的数据Before Image。执行业务 SQL。查询操作后的数据After Image。生成 undo_log 记录。向 TCTransaction Coordinator注册分支并申请全局锁。本地事务提交注意这里本地锁已经释放了。二阶段Phase 2如果决议是 Commit异步删除 undo_log释放全局锁速度极快。如果决议是 Rollback利用 undo_log 中的 Before Image 生成反向 SQL 进行补偿释放全局锁。3. 核心机制深度解析UndoLog 与 全局锁3.1 UndoLog 表结构在使用 Seata AT 模式前必须在每个业务库中创建 undo_log 表CREATE TABLE undo_log ( id bigint(20) NOT NULL AUTO_INCREMENT, branch_id bigint(20) NOT NULL, xid varchar(100) NOT NULL, context varchar(128) NOT NULL, rollback_info longblob NOT NULL, -- 存储 Before/After Image log_status int(11) NOT NULL, log_created datetime NOT NULL, log_modified datetime NOT NULL, PRIMARY KEY (id), UNIQUE KEY ux_undo_log (xid,branch_id) ) ENGINEInnoDB AUTO_INCREMENT1 DEFAULT CHARSETutf8;3.2 为什么需要全局锁Global Lock这是 Seata AT 区别于传统 XA 的关键。XA在 Phase 1 完成后持有数据库本地锁直到 Phase 2 结束才释放。这导致并发度极低。Seata AT在 Phase 1 结束时直接提交本地事务释放数据库本地锁。风险来了本地锁释放了意味着其他线程甚至是不走 Seata 的本地事务可以修改这条数据。如果此时全局事务需要回滚数据已经被别人改脏了怎么回滚这就需要全局锁。全局锁是由TC (Seata Server)维护的一张逻辑锁表。4. 脏写问题与读写隔离分析 (Highlight)我们来分析一个极端并发场景写隔离Write Isolation。场景Seata 全局事务 vs 此时的另一个事务假设我们有一个表 account字段 money 100。4.1 情况一两个 Seata 全局事务并发写Tx1开始Update money 90。Tx1 获取本地锁。Tx1 获取全局锁(Key: account:1)。Tx1 提交本地事务释放本地锁但持有全局锁。Tx2开始想要 Update money 80。Tx2 获取本地锁。Tx2 尝试获取全局锁(Key: account:1)。结果Tx2 获取全局锁失败被 Tx1 占有。Tx2 会进行重试默认重试 30次间隔 10ms。如果 Tx1 在 Phase 2 提交或回滚后释放全局锁Tx2 才能继续。如果 Tx2 等待超时回滚本地事务。结论Seata 所有的全局事务依靠 TC 端的全局锁保证了互斥不会出现脏写。4.2 情况二Seata 全局事务 vs 原生本地事务最危险的情况如果不通过 Seata直接用 JDBC 或者 Navicat 修改数据会发生什么Tx1 (Seata):Update money 100 - 90。Before Image 100, After Image 90。拿到全局锁本地 Commit。Tx2 (Native JDBC):Update money 90 - 80 (Tx2 不需要全局锁直接拿到 DB 锁修改)。Tx2 Commit。Tx1 发生异常触发二阶段回滚:Tx1 对比当前数据库值Current Value与 Phase 1 的 After Image。Tx1 发现Current(80) ! After Image(90)。结果回滚失败这种情况被称为脏写导致的无法回滚。Seata 会记录异常日志需要人工介入。4.3 如何防止情况二GlobalLock 的作用Seata 的设计前提是为了数据一致性所有涉及该表的写操作都必须受 Seata 控制。如果你有一个接口只需要本地事务不需要分布式事务传播但它涉及的表可能被其他全局事务操作你应该使用 GlobalLock 注解。Service public class AccountService { // 这是一个参与分布式事务的方法 GlobalTransactional public void deduct(String userId, int money) { jdbcTemplate.update(update account set money money - ? where id ?, money, userId); } // 这是一个只做本地更新的方法但为了防止破坏全局事务的一致性 // 加上 GlobalLock它会在执行 Update 前尝试检查全局锁 GlobalLock Transactional public void updateSafe(String userId, int money) { // Seata 代理会拦截 // 1. 获取本地锁 // 2. 尝试获取全局锁如果拿不到说明有全局事务正在操作这行数据需等待 // 3. 执行 SQL // 4. 提交 jdbcTemplate.update(update account set money ? where id ?, money, userId); } }4.4 读隔离Read Isolation在 AT 模式下默认的隔离级别是读未提交Read Uncommitted针对全局视角。因为 Tx1 在 Phase 1 就提交了Tx2 即使在 Tx1 全局未完成时也能读到 Tx1 修改后的数据。如果业务需要全局读已提交Global Read Committed必须使用 SELECT ... FOR UPDATE 配合 GlobalLock 或 GlobalTransactional。Seata 代理增强逻辑如下解析到 SELECT ... FOR UPDATE。查询是否持有全局锁。如果有全局锁说明有未完成的全局写事务则等待锁释放。读取数据此时读到的就是全局已提交的数据。5. 实际代码演示5.1 Maven 依赖dependency groupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-seata/artifactId /dependency5.2 业务逻辑实现一个电商下单流程Order-Service 调用 Storage-Service 和 Account-Service。Order Service (TM):Service public class OrderServiceImpl implements OrderService { Autowired private StorageFeignClient storageFeignClient; Autowired private AccountFeignClient accountFeignClient; Autowired private OrderMapper orderMapper; // xid 会通过 Feign 拦截器自动透传 GlobalTransactional(name create-order-tx, rollbackFor Exception.class) Override public void create(Order order) { LOGGER.info(-----开始新建订单); // 1. 本地创建订单 orderMapper.create(order); // 2. 远程扣减库存 LOGGER.info(-----订单微服务开始调用库存做扣减); storageFeignClient.decrease(order.getProductId(), order.getCount()); // 3. 远程扣减账户 LOGGER.info(-----订单微服务开始调用账户做扣减); accountFeignClient.decrease(order.getUserId(), order.getMoney()); // 模拟异常测试回滚 // int i 1 / 0; LOGGER.info(-----订单结束); } }Storage Service (RM):Service public class StorageServiceImpl implements StorageService { Autowired private StorageMapper storageMapper; // 不需要 GlobalTransactional只需要普通的 Transactional // Seata 的代理源会自动识别 XID 并加入事务 Transactional Override public void decrease(Long productId, Integer count) { LOGGER.info(-------库存微服务收到 XID: RootContext.getXID()); // 这里的 SQL 执行会被 Seata 代理生成 UndoLog 并注册全局锁 storageMapper.decrease(productId, count); } }6. 总结与权衡优点高性能Phase 1 直接提交本地事务不长时间占用数据库连接。零侵入不需要像 TCC 那样写三段式代码开发效率高。自动补偿框架自动生成回滚 SQL。缺点与风险脏写风险必须确保所有涉及该数据的写操作都经过 Seata 体系使用 GlobalLock否则会产生无法回滚的脏数据。性能损耗由于需要解析 SQL、生成 Before/After Image、序列化 UndoLog相比原生 JDBC 有一定性能损耗约降低 30%-50% 的写吞吐。全局锁争抢在热点数据场景下如扣减秒杀库存全局锁的竞争会导致严重的性能下降此时不建议使用 AT 模式建议使用 TCC 或 Redis 方案。