【鹅厂一面真题】数据库乐观锁和悲观锁以及redis分布式锁的区别和使用场景？

1.40.1 面试考察重点

1. 面试官的考察目标

• 锁机制理解：对各类锁实现原理的掌握程度
• 场景适配：不同业务场景下的技术选型能力
• 问题诊断：锁冲突问题的解决思路
• 实战经验：实际应用中的权衡经验

2. 关键关注点

• 实现原理：各类锁的底层工作机制
• 性能影响：对系统吞吐量的影响
• 数据一致：保证数据正确性的方式
• 适用边界：各类锁的优缺点对比

由于篇幅限制，只能给大家展示小部分内容，

全套面试笔记及答案【点击此处】即可免费获取

1.40.2 面试核心知识点详解

在并发编程和分布式系统中，乐观锁、悲观锁、Redis 分布式锁 是常见的并发控制机制，它们的核心目标是 保证数据一致性 ，但实现方式、适用场景和优缺点差异显著。以下是详细对比和使用场景分析：

1.40.2.1 数据库乐观锁（Optimistic Lock）

• 核心思想 ：假设冲突很少发生（“乐观”），在提交更新时检查版本号或时间戳。
• 实现方式 ：
  • 使用版本号（version）字段或时间戳（timestamp）字段。
  • 更新时通过 WHERE 条件判断版本是否被修改。
• 示例 ：

UPDATE inventory SET stock = stock - 1, version = version + 1
WHERE product_id = 1001AND version = 1;

✅ 优点

• 性能高 ：避免长时间加锁，减少锁竞争。
• 并发性强 ：适合读多写少的场景。
• 开销小 ：仅在提交时进行版本校验。

❌ 缺点

• 冲突处理复杂 ：若冲突频繁，需重试或报错。
• 无法保证绝对一致性 ：依赖业务逻辑处理冲突。

📌 使用场景

• 高并发、低冲突 ：如电商秒杀、库存扣减。
• 弱一致性要求 ：如缓存更新、非关键数据修改。
• 幂等性操作 ：如订单状态变更（允许多次尝试）。

1.40.2.2 数据库悲观锁（Pessimistic Lock）

原理

• 核心思想 ：假设冲突频繁发生（“悲观”），在事务开始时即加锁，防止其他事务修改。
• 实现方式 ：
  • SELECT ... FOR UPDATE（行级锁）。
  • SELECT ... LOCK IN SHARE MODE（共享锁）。
• 示例 ：

START TRANSACTION;
SELECT * FROM inventory WHERE product_id = 1001FORUPDATE;
UPDATE inventory SET stock = stock - 1WHERE product_id = 1001;
COMMIT;

✅ 优点

• 强一致性 ：确保事务期间数据不被修改。
• 简单直接 ：无需版本号或重试逻辑。

❌ 缺点

• 性能低 ：锁竞争可能导致阻塞，影响吞吐量。
• 死锁风险 ：多个事务交叉加锁可能引发死锁。
• 资源占用高 ：长时间持有锁会消耗数据库连接池资源。

📌 使用场景

• 严格一致性要求 ：如银行转账、财务流水。
• 写操作频繁 ：如订单创建、库存锁定。
• 短事务场景 ：避免长时间持有锁。

1.40.2.3 Redis 分布式锁（Distributed Lock）

原理

• 核心思想 ：通过 Redis 的原子操作（如 SETNX 或 Redlock 算法）实现跨服务节点的资源互斥访问。
• 实现方式 ：
  • SETNX ：SET key value NX PX timeout（原子性设置锁）。
  • Redlock ：在多个 Redis 节点上加锁，确保高可用。
• 示例（Lua 脚本实现原子性） ：

-- 加锁
if redis.call("set", KEYS[1], ARGV[1], "NX", "PX", ARGV[2]) then
returntrue
else
returnfalse
end

-- 释放锁
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
returnfalse
end

✅ 优点

• 跨服务协调 ：适用于分布式系统（如微服务、多节点集群）。
• 高性能 ：Redis 基于内存，响应速度快。
• 可扩展性强 ：支持集群部署（如 Redis Sentinel、Redis Cluster）。

❌ 缺点

• 网络依赖 ：Redis 故障可能导致锁失效。
• 死锁风险 ：未设置超时或未正确释放锁。
• 复杂性高 ：需处理锁续期（Lease）、锁竞争、脑裂等问题。

📌 使用场景

• 分布式任务调度 ：如定时任务去重、全局计数器。
• 共享资源访问 ：如分布式限流、缓存预热。
• 跨服务协调 ：如订单状态同步、分布式事务协调。

 

1.40.2.4 三者对比表

特性	乐观锁	悲观锁	Redis 分布式锁
适用场景	读多写少、低冲突	写多读少、高一致性要求	分布式系统、跨服务协调
一致性保障	最终一致性（需重试）	强一致性	弱一致性（需超时机制）
性能	高（无锁竞争）	低（锁竞争）	高（基于内存）
复杂度	低（需版本号）	中（需事务管理）	高（需 Lua 脚本、超时）
死锁风险	无	有	有（未设置超时）
资源占用	低	高（连接池占用）	中（Redis 内存占用）
分布式支持	否	否	是

1.40.2.5 典型使用场景对比

场景	推荐锁类型	原因
电商秒杀库存扣减	乐观锁	高并发、低冲突，允许部分失败重试
银行转账	悲观锁	强一致性要求，需防止并发修改
分布式限流	Redis 分布式锁	多节点共享限流状态，需跨服务协调
订单状态变更	乐观锁	幂等性操作，允许冲突后重试
缓存预热	Redis 分布式锁	防止多个节点重复加载数据
全局唯一 ID 生成	Redis 分布式锁	需确保多个服务实例生成唯一 ID
库存锁定（下单阶段）	悲观锁	短事务内锁定库存，防止超卖
分布式任务调度	Redis 分布式锁	防止多个节点重复执行任务

……