【面试】分布式事务与分布式锁：核心原理与工程实践

最新推荐文章于 2025-11-26 16:40:48 发布

原创最新推荐文章于 2025-11-26 16:40:48 发布 · 627 阅读

11 ·

CC 4.0 BY-SA版权

文章标签：

#面试 #分布式 #职场和发展

java常见的面试题和回答思路专栏收录该内容

28 篇文章

订阅专栏

文章目录

- - **总结**

1. 分布式事务：一致性难题的解决之道

在分布式系统中，事务的ACID特性难以直接满足。核心解决思路是通过柔性事务替代强一致性，具体方案包括：

1.1 两阶段提交（2PC）

原理：协调者（Coordinator）主导，参与者（Participant）分阶段执行（Prepare & Commit/Rollback）。
痛点：同步阻塞、协调者单点故障。
适用场景：数据库层原生支持（如MySQL XA），但性能较差。

1.2 TCC（Try-Confirm-Cancel）

原理：业务层补偿机制，分三阶段：
- Try：预留资源（如冻结库存）。
- Confirm：确认操作（如扣减库存）。
- Cancel：回滚预留（如解冻库存）。
优势：无资源阻塞，可自定义业务逻辑。

案例：电商订单场景：

// TCC接口示例
public interface InventoryTccService {
    @Transactional
    boolean tryReserve(Long skuId, int count);
    
    @Transactional
    boolean confirmReserve(Long skuId, int count);
    
    @Transactional
    boolean cancelReserve(Long skuId, int count);
}

1.3 基于消息的最终一致性

原理：借助消息队列解耦事务步骤，如RocketMQ事务消息：
1. 发送半消息（事务中）。
2. 本地事务成功 → 提交消息。
3. 消息消费端确保业务执行。
公式：事务成功率 = 本地事务成功率 × 消息投递成功率。
适用场景：支付结果通知、日志异步处理。

1.4 Saga模式

原理：长事务拆分为多个子事务，每个子事务有对应的补偿操作。
实现：
- 编排式（Choreography）：服务间通过事件驱动。
- 协同式（Orchestration）：中心控制器调度。
案例：机票预订系统：订票 → 支付 → 出票，任一失败触发反向补偿。

2. 分布式锁：协调分布式互斥访问

分布式锁需解决互斥性、容错性、死锁预防三大问题，常见方案对比：

2.1 Redis分布式锁

实现：SET key random_value NX PX 30000（Redisson封装）。
隐患：
- 锁过期时间设置不当导致并发冲突（需续期机制）。
- 主从切换可能丢锁（RedLock算法争议大）。

最佳实践：

RLock lock = redisson.getLock("orderLock");
try {
    lock.lock(30, TimeUnit.SECONDS); // 自动续期
    // 业务逻辑
} finally {
    lock.unlock();
}

2.2 ZooKeeper分布式锁

原理：基于临时顺序节点（EPHEMERAL_SEQUENTIAL）和Watch机制。
流程：
1. 创建临时有序节点。
2. 判断是否为最小节点 → 获得锁。
3. 若非最小，监听前序节点释放。
优势：强一致性，无锁过期问题。
缺陷：性能低于Redis，频繁Watch消耗资源。

2.3 etcd/Consul的分布式锁

原理：基于租约（Lease）和键值对比（Compare-and-Swap）。
特点：高可用、强一致，适合K8s环境集成。

3. 面试回答技巧：结合业务场景

分布式事务选型：
- 强一致需求：优先考虑2PC（如银行核心系统）。
- 高并发场景：TCC或消息队列（如秒杀库存扣减）。
- 长事务：Saga模式（如跨境物流）。
分布式锁选型：
- 简单场景：Redis锁（注意续期和集群模式）。
- 强一致需求：ZooKeeper（如主选举）。
- 云原生环境：etcd（如分布式任务调度）。