企业官网建设流程全解析

门户网站有,做国外网站,网站的访问量怎么查,八里河风景区网站建设内容摘要标签#xff1a; #Seata #分布式事务 #微服务 #SpringCloud #架构设计 #Java#x1f4a3; 前言#xff1a;微服务拆分后的“噩梦” 假设一个电商下单流程#xff1a; 订单服务#xff1a;创建订单 (INSERT ORDER).库存服务#xff1a;扣减库存 (UPDATE STOCK SET count …标签#Seata #分布式事务 #微服务 #SpringCloud #架构设计 #Java 前言微服务拆分后的“噩梦”假设一个电商下单流程订单服务创建订单 (INSERT ORDER).库存服务扣减库存 (UPDATE STOCK SET count count - 1).如果没有分布式事务当库存扣减成功但网络超时导致订单服务回滚时库存就永久丢失了超卖/少卖。 一、 Seata AT 模式黑科技般的“时光倒流”AT (Automatic Transaction)模式是 Seata 的默认模式主打“无侵入”。你依然像写本地事务一样写代码Seata 在底层帮你搞定一切。1. 原理核心Undo LogSeata 会代理 JDBC 数据源。当你执行 SQL 时Seata 会拦截第一阶段 (Prepare)解析 SQL查询更新前的数据Before Image。执行 SQL查询更新后的数据After Image。把 Before/After Image 存入undo_log表。提交本地事务。第二阶段 (Commit/Rollback)Commit异步删除undo_log。Rollback根据undo_log中的 Before Image生成反向 SQL 把数据改回去。AT 模式流程图 (Mermaid):1. 开启全局事务2. 调用业务2. 调用业务3. 报告状态4. 决议: 全局提交/回滚AT 模式内部逻辑拦截查询快照保存业务 SQLSeata DataSource Proxy生成 Before/After Imageundo_log 表提交本地事务TM 事务管理器TC 事务协调者RM 订单服务RM 库存服务2. 代码实战代码极其简单只需要在发起方加上GlobalTransactional。// 订单服务GlobalTransactional(namecreate-order-tx,rollbackForException.class)publicvoidcreateOrder(StringuserId,StringcommodityCode,intcount){// 1. 本地逻辑创建订单orderMapper.insert(newOrder(userId,commodityCode,count));// 2. 远程调用扣减库存 (Feign)// 库存服务那边只需要普通的 Transactional 即可storageClient.deduct(commodityCode,count);}3. 致命弱点全局锁 (Global Lock)为了防止脏写 (Dirty Write)Seata 在 AT 模式下需要获取全局锁。在高并发热点商品扣减库存时所有事务都要排队争抢同一行记录的全局锁。结论AT 模式不适合高并发抢购场景。️ 二、 Seata TCC 模式硬核的“资源预留”TCC (Try-Confirm-Cancel)模式不依赖数据库的 ACID而是把逻辑上升到业务层。它要求开发者为每个操作实现三个方法。1. 原理核心资源预留Try资源检测和预留冻结库存。Confirm真正的业务提交使用冻结的库存。Cancel业务回滚释放冻结的库存。2. 库存扣减的 TCC 设计我们需要在数据库表中增加一个frozen(冻结) 字段。Try 阶段UPDATE stock SET count count - 1, frozen frozen 1 WHERE id 1(库存没真扣只是挪到了冻结区)Confirm 阶段UPDATE stock SET frozen frozen - 1 WHERE id 1(真正的扣减消耗冻结区)Cancel 阶段UPDATE stock SET count count 1, frozen frozen - 1 WHERE id 1(回滚把冻结区的库存还回去)TCC 流程图 (Mermaid):1. Try 阶段成功失败2. Cancel 阶段 (回滚)库存 Cancel: 解冻库存2. Confirm 阶段 (提交)库存 Confirm: 扣除冻结TM库存 Try: 冻结库存3. 代码实战代码量激增需要定义接口。// 定义 TCC 接口LocalTCCpublicinterfaceStorageTccService{// Try: 返回 boolean 或 void一定要加上 TwoPhaseBusinessActionTwoPhaseBusinessAction(namedeductStock,commitMethodcommit,rollbackMethodrollback)booleantryDeduct(BusinessActionContextParameter(paramNamecode)StringcommodityCode,BusinessActionContextParameter(paramNamecount)intcount);// Confirmbooleancommit(BusinessActionContextcontext);// Cancelbooleanrollback(BusinessActionContextcontext);}4. 核心优势无锁高性能TCC 的锁在数据库行锁层面本地事务短没有全局锁。Try 阶段虽然锁了行但提交极快。更厉害的是TCC 不依赖数据库你甚至可以用 Redis 来做库存扣减Try 在 Redis 冻结Confirm 在 Redis 删除。⚔️ 三、 AT vs TCC巅峰对决维度AT 模式 (自动)TCC 模式 (手动)代码侵入性极低(注解即可)极高(写3个方法)开发效率高低性能中 (受限于全局锁)高(无全局锁)适用场景后台管理、低并发业务核心交易、高并发、Redis/非DB资源复杂性依赖 undo_log 表需处理空回滚、悬挂、幂等 四、 艰难抉择到底选谁回到我们的场景订单与库存。1. 场景 A普通的 B2B 采购系统 (QPS 100)选择AT 模式。原因开发快维护简单并发低全局锁不会成为瓶颈。没必要为了那一丢丢性能去写复杂的 TCC。2. 场景 B双十一大促 / 直播带货 (QPS 1000)选择TCC 模式(甚至结合 Redis)。原因AT 模式的全局锁会导致大量事务等待拖垮数据库。TCC 允许你在 Try 阶段预占用资源且优化空间极大例如将库存放入 Redis 做 TCC。 总结能用 AT 就用 AT毕竟“懒”是程序员的美德。性能瓶颈上 TCC这是架构师能力的体现。TCC 的三个坑一定要注意处理空回滚(未 Try 先 Cancel)、幂等(多次 Cancel)、悬挂(Cancel 比 Try 先到)。Next Step:如果你的业务并发极高TCC 都嫌慢那就只能上RocketMQ 事务消息了。那是“最终一致性”的领域虽然不再保证强一致但能获得极致的吞吐量。建议去了解一下 RocketMQ 的Half Message机制。