千万级订单的分布式事务一致性问题

案例一：解决千万级订单的分布式事务一致性问题

S（情境）

• 业务背景：某电商平台日均订单量突破1000万，订单支付与库存扣减分属不同服务（订单服务、库存服务），需跨服务保证事务一致性。
• 核心痛点：
  • 支付成功后库存扣减失败，导致超卖（用户体验差、资损风险）。
  • 传统2PC（两阶段提交）性能差（TPMC仅500），无法支撑高并发。

T（任务）

• 核心目标：
  • 实现跨服务最终一致性，事务成功率≥99.99%。
  • 系统TPMC（每分钟事务数）提升至5000+。
• 挑战：
  • 高并发下如何避免本地事务与消息发送的原子性问题。
  • 补偿机制如何设计以覆盖所有异常场景（如消息丢失、服务宕机）。

A（行动）

1. 技术选型：

   • 采用 RocketMQ事务消息（半消息机制）替代2PC，降低锁冲突。
   • 引入 本地事务表 + 异步补偿任务 兜底。

2. 方案实现：

   • 事务消息流程：
     1. 订单服务发送半消息到RocketMQ。
     2. 执行本地事务（订单状态更新为“支付中”）。
     3. 提交消息，触发库存服务消费扣减库存。
     4. 若库存扣减失败，RocketMQ回查订单状态，触发补偿退款。
   • 补偿机制设计：
     • 本地事务表：记录事务状态（进行中/已完成），补偿任务扫描超时事务。
     • 幂等控制：通过订单号+版本号避免重复扣减。

3. 性能优化：

   • 消息批量提交（每批100条），减少网络开销。
   • 库存服务缓存热点商品库存，合并扣减请求。

R（结果）

• 事务成功率：从95%提升至99.99%（日均异常订单从5万降至100以内）。
• 系统性能：TPMC从500提升至6200，RT（响应时间）从200ms降至50ms。
• 扩展性：方案复用于其他场景（如优惠券核销、积分兑换）。

---

案例二：单体架构拆分为微服务的落地过程

S（情境）

• 原系统问题：
  • 单体应用（50万行代码）迭代困难，编译部署耗时30分钟以上。
  • 数据库单表数据超10亿，查询性能骤降（主库CPU长期90%+）。
• 业务需求：支撑日均1亿用户访问，快速响应需求变更。

T（任务）

• 核心目标：
  • 6个月内完成核心服务拆分，发布效率提升50%。
  • 保证拆分过程业务无损（零故障、零数据丢失）。
• 挑战：
  • 如何识别服务边界，避免过度拆分。
  • 数据迁移如何实现平滑过渡。

A（行动）

1. 拆分策略（领域驱动设计）

   • 领域划分：通过事件风暴（Event Storming）识别核心领域（用户、订单、商品、支付）。
   • 服务定义：
     • 用户服务：用户注册、登录、鉴权。
     • 订单服务：下单、状态流转、查询。
     • 商品服务：SKU管理、库存扣减。
   • 防腐层（ACL）：在单体与微服务间封装适配层，逐步替换旧逻辑。

2. 数据迁移方案

   • 双写阶段：
     1. 新服务与单体同时写新旧数据库。
     2. 通过Binlog监听旧库变更，同步到新库（延迟<1s）。
   • 增量同步：
     • 使用 Canal 解析MySQL Binlog，写入Kafka。
     • 新服务消费Kafka消息，补全数据差异。
   • 校验切换：
     • 对比新旧库关键数据（如订单总金额、用户数），差异<0.01%后切流量。

3. 灰度发布机制

   • 流量染色：通过网关标记请求（如HTTP Header X-Gray: v2），路由到新服务。
   • 渐进式发布：
     1. 内部员工（10%）→ 特定用户（1%）→ 全量用户。
     2. 每阶段观察24小时，监控错误率、RT、数据库负载。
   • 回滚方案：
     • 5分钟内可切换回单体，通过Nginx反向代理保留旧入口。

R（结果）

• 性能提升：数据库主库CPU从90%降至30%，订单查询RT从2s降至200ms。
• 迭代效率：单服务编译部署时间从30分钟降至3分钟，需求交付周期缩短40%。
• 稳定性：灰度期间零故障，数据迁移丢失率<0.001%。

---

总结技巧

1. 数据量化：所有结果均用数字体现（如性能提升XX%，故障率下降XX%）。
2. 技术细节：深入描述架构图、关键代码（如补偿任务伪代码）、工具链（Canal/Kafka）。
3. 难点升华：突出决策背后的权衡（如选择最终一致性而非强一致性）。
4. 业务价值：关联技术成果与商业指标（如GMV提升、客诉减少）。

通过以上结构化表达，面试官可清晰感知你的 技术深度、架构思维 和 业务敏感度。