企业官网建设流程全解析

网站建设 镇江丹阳,app网站搭建,深圳住房和建设局网站业务主题,深圳网站设计公司在什么地方先喝口水#xff0c;再看一眼分布式系统#xff0c;然后你会发现#xff1a;没有事务#xff0c;心里没底#xff1b;有了事务#xff0c;系统要命。作为一名写了很多年 Java 的老兵#xff0c;今天我们来聊一个在微服务世界里既不完美、但很实用的方案——Saga 分布式事…先喝口水再看一眼分布式系统然后你会发现没有事务心里没底有了事务系统要命。作为一名写了很多年 Java 的老兵今天我们来聊一个在微服务世界里既不完美、但很实用的方案——Saga 分布式事务模式。一、为什么需要 Saga问题从哪来在单体应用里事务是这样的BEGIN A 表扣钱 B 表加库存 C 表创建订单 COMMIT / ROLLBACK一切都很美直到服务被拆成了微服务数据库被拆成了多个库本地事务失效了你会发现分布式系统里没有一个“全局数据库事务”在等你。传统方案的问题2PC / XA强一致强依赖强性能杀手于是我们开始思考能不能不要强一致但系统还能跑答案就是Saga。二、Saga 是什么一句话版本Saga 一连串本地事务 对应的补偿事务换句话说每一步都先提交如果后面失败了就按相反顺序补偿回去听起来是不是有点像“做错了事靠后悔药解决。”没错但这药在分布式系统里很值钱。三、Saga 的核心思想重要但不复杂1️⃣ 本地事务优先每个服务只操作自己的数据库使用本地事务Spring Transactional 那套2️⃣ 失败 ≠ 回滚Saga 的世界里失败不是 rollback而是执行补偿操作Compensation Action3️⃣ 最终一致性中间状态可能不一致但最终能“对上账”一句话总结Saga 不保证你时时开心但保证你最后不崩。四、Saga 的两种经典实现方式方式一编排式 SagaOrchestration⭐ 推荐有一个指挥官统一调度流程。InventoryServicePaymentServiceOrderServiceSagaCoordinatorInventoryServicePaymentServiceOrderServiceSagaCoordinator创建订单扣款扣库存失败退款补偿取消订单补偿优点流程清晰易于监控逻辑集中缺点指挥官可能变胖但对 Java 后端来说这个“胖”是可以接受的。方式二编舞式 SagaChoreography没有指挥官全靠服务自己“看消息办事”。事件事件失败事件补偿事件OrderPaymentInventory优点去中心化缺点链路难追踪Debug 靠信仰一旦系统大了没人知道谁在跳哪支舞。五、一个下单场景的 Saga 示例Java 思路正向流程创建订单Order Service扣减余额Payment Service扣减库存Inventory Service补偿流程库存失败 → 退款 → 取消订单伪代码示例编排式publicvoidcreateOrderSaga(CreateOrderCmdcmd){try{orderService.create(cmd);paymentService.pay(cmd);inventoryService.deduct(cmd);}catch(Exceptione){inventoryService.compensate(cmd);paymentService.refund(cmd);orderService.cancel(cmd);throwe;}}看起来很普通对吧但它解决的是分布式事务这个“世纪难题”。六、Saga 的几个关键设计点血泪经验1️⃣ 补偿必须是幂等的可能被调用多次不能多退钱、多加库存幂等不是优化是底线。2️⃣ 补偿 ≠ 完全回滚有些操作不可逆比如发短信补偿只能“业务上对等”分布式系统里时间不能倒流只能对冲。3️⃣ 一定要有状态表Saga 实例状态当前执行到哪一步是否已补偿否则系统一重启你会失忆。七、Saga vs 2PC快速对比维度Saga2PC一致性最终一致强一致性能高低实现复杂度中高可用性高低微服务友好度⭐⭐⭐⭐⭐⭐结论一句话微服务时代用 Saga银行核心用 2PC。八、Java 技术栈中的 Saga 实践常见组合Spring BootSpring Transaction消息队列Kafka / RocketMQ状态表 定时补偿进阶框架AxonEventuate Tram自研 Saga Coordinator很多公司最终都会走这条路