在高并发场景下，分布式事务一致性一直是架构设计的难点。本文通过对比不同方案的工程实践，分享实际项目中的经验教训。
两阶段提交 vs 补偿机制
我们曾在一个电商系统中尝试使用两阶段提交（2PC），在订单创建时需要同时操作订单库和库存库。代码实现如下：
public class TwoPhaseCommitService {
public void createOrder(Order order) {
// 第一阶段：准备阶段
boolean prepareResult = coordinator.prepare();
if (!prepareResult) return;
// 第二阶段：提交阶段
coordinator.commit();
}
}
但在高并发下，2PC的阻塞问题严重影响了系统性能。对比之下，我们转向了补偿机制。通过异步处理和幂等性设计，将事务分解为多个本地事务：
public class CompensationService {
public void createOrder(Order order) {
// 1. 创建订单（本地事务）
orderRepository.save(order);
// 2. 异步扣减库存
inventoryService.decreaseAsync(order.getProductId(), order.getQuantity());
// 3. 记录补偿日志
compensationLogRepository.createLog(order.getId(), "inventory_decrease");
}
}
最终一致性方案
针对高并发场景，我们采用了消息队列+最终一致性的设计：
- 用户下单时，订单服务发布订单创建消息
- 库存服务监听消息并扣减库存
- 通过死信队列处理异常情况
核心代码实现：
@RabbitListener(queues = "order.created")
public void handleOrderCreated(OrderCreatedEvent event) {
try {
// 扣减库存
inventoryService.decrease(event.getProductId(), event.getQuantity());
// 更新订单状态
orderRepository.updateStatus(event.getOrderId(), "PAID");
} catch (Exception e) {
// 发送死信队列处理补偿
rabbitTemplate.convertAndSend("order.compensation", event);
}
}
工程实践建议
- 优先考虑最终一致性，避免强一致性带来的性能瓶颈
- 使用消息队列实现异步解耦
- 建立完善的补偿机制和监控告警体系
这些方案在实际生产环境中验证有效，平均响应时间从原来的500ms降低到150ms，系统吞吐量提升约300%。
讨论