Redis面试常问的相关问题

前置条件：从节点连接主节点#

从节点通过配置 / 命令指定主节点地址，建立连接：

1
# 方式1：配置文件（redis.conf）
2
replicaof 192.168.1.100 6379  # Redis 5.0+ 用replicaof，旧版本用slaveof
3
masterauth 123456  # 主节点有密码时配置
4

5
# 方式2：运行时命令
6
127.0.0.1:6379> replicaof 192.168.1.100 6379
7
127.0.0.1:6379> config set masterauth 123456

场景 1：全量同步（Full Resync）#

触发时机：

• 从节点首次连接主节点；
• 从节点失联后重新连接，主节点的复制积压缓冲区中没有对应的偏移量数据；
• 从节点发送的 PSYNC 命令中，主节点的 runid 不匹配（如主节点重启后 runid 变化）。

全量同步完整流程（10 个步骤，附流程图）：

1
graph TD
2
    A[从节点发送PSYNC ? -1 命令] --> B[主节点接收命令，判断需全量同步]
3
    B --> C[主节点执行BGSAVE生成RDB文件]
4
    C --> D[主节点将新写命令写入复制积压缓冲区]
5
    D --> E[主节点发送FULLRESYNC + runid + offset给从节点]
6
    E --> F[从节点保存runid和offset，清空旧数据]
7
    F --> G[主节点发送RDB文件给从节点]
8
    G --> H[从节点接收并加载RDB文件（阻塞读请求）]
9
    H --> I[主节点发送复制积压缓冲区中的写命令给从节点]
10
    I --> J[从节点执行这些命令，同步offset到主节点水平]

步骤拆解（通俗易懂版）：

1. 从节点发起同步请求：从节点连接主节点后，发送 PSYNC ? -1 命令（? 表示未知主节点 runid，-1 表示偏移量为 - 1，请求全量同步）；
2. 主节点准备全量数据：主节点收到请求后，执行 BGSAVE 命令（后台生成 RDB 文件，不阻塞主节点写操作）；
3. 主节点缓存新写命令：生成 RDB 期间，主节点将新收到的写命令写入 “复制积压缓冲区”（避免这部分数据丢失）；
4. 主节点发送同步指令：主节点向从节点发送 FULLRESYNC {runid} {offset} 指令，告知从节点 “需要全量同步，我的 runid 是 XXX，当前偏移量是 XXX”；
5. 从节点准备接收数据：从节点保存主节点的 runid 和 offset，清空自己的旧数据（避免数据冲突）；
6. 主节点传输 RDB 文件：主节点将生成的 RDB 文件发送给从节点；
7. 从节点加载 RDB 文件：从节点接收 RDB 文件后，加载到内存（此阶段从节点阻塞，无法处理读请求）；
8. 主节点同步增量命令：RDB 传输完成后，主节点将 “复制积压缓冲区” 中的写命令发送给从节点；
9. 从节点执行增量命令：从节点执行这些命令，将自己的 offset 同步到主节点的水平，完成全量同步。

场景 2：增量同步（Partial Resync）#

触发时机：

• 从节点短暂失联（如网络抖动）后重新连接主节点；
• 主节点的复制积压缓冲区中，仍保存着从节点失联期间的写命令；
• 从节点发送的 PSYNC 命令中，主节点的 runid 匹配，且偏移量在复制积压缓冲区范围内。

增量同步完整流程：

1
graph TD
2
    A[从节点发送PSYNC {runid} {offset}命令] --> B[主节点校验runid和offset]
3
    B --> C{校验通过？}
4
    C -- 是 --> D[主节点从复制积压缓冲区中，读取offset之后的写命令]
5
    D --> E[主节点发送CONTINUE指令+这些写命令给从节点]
6
    E --> F[从节点执行命令，更新自己的offset]
7
    C -- 否 --> G[发全量同步]

步骤拆解：

1. 从节点发起增量请求：从节点重新连接主节点后，发送 PSYNC {主节点runid} {自己当前的offset} 命令，告知主节点 “我之前同步到了这个偏移量，请求继续同步”；
2. 主节点校验信息：主节点检查 runid 是否匹配（确认是同一个主节点），并检查从节点的 offset 是否在 “复制积压缓冲区” 的范围内；
3. 主节点发送增量命令：校验通过后，主节点从复制积压缓冲区中，读取从节点 offset 之后的所有写命令，发送给从节点；
4. 从节点执行命令：从节点执行这些写命令，将自己的 offset 更新到主节点的水平，完成增量同步；
5. 校验失败兜底：若 runid 不匹配（如主节点重启）或 offset 超出缓冲区范围，主节点会触发全量同步。

1. 复制积压缓冲区的核心作用#

• 是主节点维护的固定长度环形缓冲区（默认 1MB，可通过 repl-backlog-size 配置）；
• 仅存储最近的写命令，用于增量同步，缓冲区越大，支持的从节点失联时间越长；
• 实战建议：根据业务写 QPS 调整大小（如写 QPS=10 万 /s，需支持 10 秒失联，则配置 repl-backlog-size 1GB）。

2. 异步复制的 “数据延迟” 问题#

• 主节点写操作完成后，异步将命令发送给从节点，因此从节点数据会比主节点 “慢一拍”（延迟通常在毫秒级）；

• 实战优化：

  • 减少主从节点的网络延迟（同机房部署）；
  • 避免主节点执行大命令（如 KEYS *），导致同步阻塞；
  • 通过 info replication 查看 slave_repl_offset 和 master_repl_offset，监控同步延迟。

3. 主节点 BGSAVE 阻塞问题#

• 全量同步时，主节点执行 BGSAVE 生成 RDB 文件，若数据量过大（如 10GB），BGSAVE 会消耗大量 CPU / 磁盘 IO，可能导致主节点短暂卡顿；

• 实战优化：

  • 主节点配置 rdbcompression yes（压缩 RDB 文件，减少传输时间）；
  • 避开业务高峰期进行首次全量同步；
  • 级联复制（从节点挂载到从节点上，减少主节点的同步压力）。

4. 从节点加载 RDB 的阻塞问题#

• 从节点加载 RDB 文件时会阻塞所有读请求，若 RDB 文件过大，阻塞时间会很长；

• 实战优化：

  • 从节点配置 repl-disable-tcp-nodelay no（开启 TCP_NODELAY，减少同步延迟）；
  • 从节点使用固态硬盘（SSD），提升 RDB 加载速度；
  • 分批启动从节点，避免多个从节点同时请求全量同步，压垮主节点。

5. 主从切换的注意事项#

• 主节点宕机后，从节点可通过 replicaof no one 升级为主节点；
• 新主节点的 runid 会变化，其他从节点重新连接时会触发全量同步，需提前配置足够大的复制积压缓冲区。

一、Redis 过期键的三种核心删除策略#

Redis 中设置过期时间的键（如 SET key val EX 60），核心有三种理论删除策略，每种策略的设计思路和优缺点截然不同：

1. 定时删除（Timed Deletion）#

• 执行逻辑

  当你给键设置

  1
  EX 60

  时，Redis 会创建一个定时器，60 秒后定时器触发，Redis 立即删除该键。

• 核心问题

  若 Redis 中有 10 万个过期键，就需要维护 10 万个定时器，定时器的创建、管理会占用大量 CPU 资源；高并发场景下，CPU 会被定时器调度占满，导致 Redis 处理业务请求的能力大幅下降。

2. 惰性删除（Lazy Deletion）#

• 执行逻辑

  过期键不会被主动删除，只有当你执行

  1
  GET key

  时，Redis 才会检查该键是否过期：

  • 未过期：正常返回值；
  • 已过期：删除该键，返回 (nil)。

• 核心优势

  完全不消耗 CPU 资源在 “提前删除” 上，仅在用户访问时做检查，是 “按需处理” 的思路。

• 核心问题

  若一个过期键长期不被访问，会一直占用内存（比如设置了

  1
  EX 60

  的键，60 天后才被访问），极端情况下会导致 Redis 内存耗尽。

3. 定期删除（Periodic Deletion）#

• 执行逻辑

  Redis 会启动一个后台线程，每隔固定时间（默认 100ms，可配置）执行一次 “过期键扫描”：

  1. 随机选取一定数量（如 20 个）的带过期时间的键；
  2. 检查这些键是否过期，删除已过期的；
  3. 若过期键占比超过 25%，则重复步骤 1-2（避免单次扫描耗时过久）；
  4. 单次扫描有时间上限（如 25ms），避免阻塞主线程。

• 核心优势

  既不会像定时删除那样消耗大量 CPU，也不会像惰性删除那样导致内存泄漏，是 “折中方案”。

• 核心问题

  键的删除存在延迟（比如 100ms 后才被扫描到），但延迟可控，且不会长期占用内存。

1. 定时器的 CPU 开销不可接受#

• Redis 是单线程（主线程处理业务请求）+ 多后台线程（处理慢操作）架构，定时删除的定时器若由主线程管理，会阻塞业务请求；若由后台线程管理，大量定时器的调度、触发会占用后台线程的全部资源。
• 举例：若有 10 万个过期键，每个定时器的创建、销毁、触发都需要 CPU 计算，Redis 的 QPS 会从 10 万 + 骤降，失去高性能优势。

2. 高并发场景下的性能抖动#

• 定时删除的定时器触发是 “突发式” 的：比如某一时刻有 1 万个定时器同时触发，Redis 会集中删除这 1 万个键，导致该时间段内业务请求响应超时，出现性能抖动。
• 而定期删除是 “匀速扫描”，单次扫描有时间上限，能保证 Redis 的响应延迟稳定。

3. 无实际必要（混合策略已足够）#

• Redis 的核心诉求是 “高性能”，而非 “绝对实时的过期键删除”—— 即使过期键延迟几秒删除，只要内存不泄漏，对大部分业务无影响。
• 定时删除的 “实时性” 收益，远低于其 CPU 开销的成本，属于 “过度设计”。

混合策略的执行流程#

1
graph TD
2
    A[Redis 运行中] --> B[客户端访问键]
3
    B --> C{键是否过期？}
4
    C -- 是 --> D[惰性删除：删除该键，返回nil]
5
    C -- 否 --> E[返回键值]
6

7
    A --> F[后台线程定期扫描（每100ms）]
8
    F --> G[随机选取20个带过期时间的键]
9
    G --> H{键是否过期？}
10
    H -- 是 --> I[删除过期键]
11
    H -- 否 --> J[跳过]
12
    G --> K{过期键占比>25%？}
13
    K -- 是 --> G
14
    K -- 否 --> L[结束本次扫描]
15

16
    A --> M[内存达到maxmemory阈值]
17
    M --> N[触发内存淘汰策略]
18
    N --> O[淘汰部分键（含过期键）]

补充：内存淘汰策略（最终兜底）#

即使有了惰性 + 定期删除，若过期键仍未被清理且 Redis 内存达到 maxmemory 阈值，Redis 会触发内存淘汰策略（如 volatile-lru：淘汰最近最少使用的过期键），进一步保证内存不溢出。

Redis 如何实现分布式锁？需要注意哪些问题（原子性、死锁、误删）？#

你想知道 Redis 实现分布式锁的核心方法，以及在实现过程中需要解决的原子性、死锁、误删等关键问题 —— 分布式锁是解决分布式系统中资源竞争的核心方案，Redis 因其高性能和易用性成为最主流的实现方式，我会从核心实现原理、关键问题解决方案、完整代码示例、注意事项四个维度，讲透 Redis 分布式锁的落地细节。

基础命令解析#

步骤 1：基础版实现（存在死锁 / 误删问题）#

1
# 客户端A获取锁（成功）
2
127.0.0.1:6379> SETNX order_lock 1
3
(integer) 1
4

5
# 客户端B获取锁（失败，锁已被占用）
6
127.0.0.1:6379> SETNX order_lock 1
7
(integer) 0
8

9
# 客户端A释放锁
10
127.0.0.1:6379> DEL order_lock
11
(integer) 1

问题：

• 死锁：若客户端 A 获取锁后宕机，未执行 DEL，锁 Key 会永久存在，其他客户端无法获取；
• 无过期时间：即使未宕机，业务执行超时也会导致锁无法释放。

步骤 2：优化版（添加过期时间，解决死锁）#

Redis 2.6.12+ 支持 SET 命令整合 NX（等价 SETNX）和 EX（过期时间），原子性设置锁 + 过期时间（解决基础版 “SETNX+EXPIRE” 非原子的问题）：

1
# 原子操作：设置锁Key，值为1，过期时间30秒，仅当Key不存在时设置
2
127.0.0.1:6379> SET order_lock 1 NX EX 30
3
OK
4

5
# 释放锁
6
127.0.0.1:6379> DEL order_lock
7
(integer) 1

核心改进：

• 原子性：SET key val NX EX ttl 是单条命令，避免 “SETNX 成功但 EXPIRE 失败” 导致的死锁；
• 过期时间：30 秒后锁自动释放，即使客户端宕机也不会永久占用锁。

仍存在问题：

• 误删锁：客户端 A 的锁因超时自动释放，客户端 B 获取锁，此时 A 业务执行完成，执行 DEL 会误删客户端 B 的锁；
• 过期时间难设置：过期时间太短，业务未执行完锁就释放；太长，锁释放延迟。

步骤 3：最终版（解决误删 + 自动续期）#

1
-- 入参：KEYS[1]=锁Key，ARGV[1]=客户端持有的锁值
2
if redis.call('get', KEYS[1]) == ARGV[1] then
3
    return redis.call('del', KEYS[1])  -- 校验通过，删除锁
4
else
5
    return 0  -- 校验失败，不删除
6
end

1. 核心工具类（解决原子性、死锁、误删）#

1
import org.springframework.data.redis.core.RedisTemplate;
2
import org.springframework.data.redis.core.script.DefaultRedisScript;
3
import org.springframework.stereotype.Component;
4

5
import javax.annotation.Resource;
6
import java.util.Collections;
7
import java.util.UUID;
8
import java.util.concurrent.TimeUnit;
9
import java.util.concurrent.locks.Condition;
10
import java.util.concurrent.locks.Lock;
11

12
@Component
13
public class RedisDistributedLock implements Lock {
14
    @Resource
15
    private RedisTemplate<String, Object> redisTemplate;
16

17
    // 锁Key前缀
18
    private static final String LOCK_PREFIX = "dist_lock:";
19
    // 锁默认过期时间（秒）
20
    private static final long DEFAULT_TTL = 30;
21
    // 客户端唯一标识（避免误删）
22
    private final String lockValue;
23
    // 当前锁Key
24
    private String lockKey;
25

26
    public RedisDistributedLock() {
27
        // 生成唯一值（UUID+线程ID）
28
        this.lockValue = UUID.randomUUID().toString() + "-" + Thread.currentThread().getId();
29
    }
30

31
    /**
32
     * 获取锁（阻塞式，直到获取成功）
33
     */
34
    @Override
35
    public void lock() {
36
        while (!tryLock()) {
37
            // 自旋等待，可优化为阻塞（如Thread.sleep(100)）
38
            Thread.yield();
39
        }
40
    }
41

42
    /**
43
     * 尝试获取锁（非阻塞）
44
     * @return true-成功，false-失败
45
     */
46
    @Override
47
    public boolean tryLock() {
48
        return tryLock(DEFAULT_TTL, TimeUnit.SECONDS);
49
    }
50

51
    /**
52
     * 尝试获取锁（带超时时间）
53
     */
54
    @Override
55
    public boolean tryLock(long time, TimeUnit unit) {
56
        long ttl = unit.toSeconds(time);
57
        // 原子操作：设置锁Key + 唯一值 + 过期时间
58
        Boolean success = redisTemplate.opsForValue().setIfAbsent(
59
                lockKey, lockValue, ttl, TimeUnit.SECONDS
60
        );
61
        // 开启看门狗（自动续期）
62
        if (Boolean.TRUE.equals(success)) {
63
            startWatchDog(ttl);
64
        }
65
        return Boolean.TRUE.equals(success);
66
    }
67

68
    /**
69
     * 释放锁（原子校验+删除）
70
     */
71
    @Override
72
    public void unlock() {
73
        // Lua脚本：校验锁值是否为当前客户端的，是则删除
74
        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
75
        DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
76
        redisScript.setScriptText(script);
77
        redisScript.setResultType(Long.class);
78

79
        // 执行脚本
80
        Long result = redisTemplate.execute(
81
                redisScript,
82
                Collections.singletonList(lockKey),
83
                lockValue
84
        );
85

86
        // 释放看门狗
87
        stopWatchDog();
88
    }
89

90
    /**
91
     * 看门狗：每隔10秒续期一次，延长锁过期时间
92
     */
93
    private void startWatchDog(long ttl) {
94
        // 用线程池执行续期任务（避免创建过多线程）
95
        new Thread(() -> {
96
            while (true) {
97
                try {
98
                    // 续期间隔：过期时间的1/3（如30秒→10秒）
99
                    Thread.sleep(ttl * 1000 / 3);
100
                    // 原子续期：仅当锁存在且值匹配时，重置过期时间
101
                    String renewScript = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('expire', KEYS[1], ARGV[2]) else return 0 end";
102
                    DefaultRedisScript<Long> script = new DefaultRedisScript<>();
103
                    script.setScriptText(renewScript);
104
                    script.setResultType(Long.class);
105

106
                    Long result = redisTemplate.execute(
107
                            script,
108
                            Collections.singletonList(lockKey),
109
                            lockValue,
110
                            String.valueOf(ttl)
111
                    );
112

113
                    // 续期失败（锁已释放/过期），退出循环
114
                    if (result == 0) {
115
                        break;
116
                    }
117
                } catch (InterruptedException e) {
118
                    Thread.currentThread().interrupt();
119
                    break;
120
                }
121
            }
122
        }).start();
123
    }
124

125
    private void stopWatchDog() {
126
        // 实际开发中需用线程池管理续期线程，此处简化为标记退出
127
    }
128

129
    // 以下为Lock接口默认实现，无需关注
130
    @Override
131
    public void lockInterruptibly() throws InterruptedException {}
132
    @Override
133
    public Condition newCondition() { return null; }
134
}

2. 使用示例（扣库存场景）#

1
@Service
2
public class StockService {
3
    @Resource
4
    private StockMapper stockMapper;
5
    @Resource
6
    private RedisDistributedLock redisLock;
7

8
    public void deductStock(Long productId) {
9
        // 设置锁Key（按商品ID粒度，避免全局锁）
10
        redisLock.setLockKey("dist_lock:stock:" + productId);
11

12
        try {
13
            // 获取锁
14
            redisLock.lock();
15

16
            // 执行业务：扣库存
17
            Stock stock = stockMapper.selectById(productId);
18
            if (stock.getNum() > 0) {
19
                stockMapper.deductNum(productId);
20
                System.out.println("库存扣减成功，剩余：" + (stock.getNum() - 1));
21
            } else {
22
                System.out.println("库存不足");
23
            }
24
        } finally {
25
            // 释放锁（必须在finally中，避免业务异常导致锁未释放）
26
            redisLock.unlock();
27
        }
28
    }
29
}

1. 原子性问题（最核心）#

• 问题场景：基础版 “SETNX + EXPIRE” 是两条命令，若 SETNX 成功后，EXPIRE 执行前客户端宕机，锁 Key 无过期时间，导致死锁；
• 解决方案：使用 SET key val NX EX ttl 原子命令，或 Lua 脚本保证多操作原子性（如释放锁时 “校验值 + 删除”）。

2. 死锁问题#

• 问题场景：客户端获取锁后宕机 / 网络中断，未释放锁，其他客户端无法获取；

• 解决方案

  1. 为锁 Key 设置合理的过期时间（如 30 秒），即使未手动释放，也会自动过期；
  2. 看门狗机制：业务执行超时前，自动续期锁的过期时间（避免锁提前释放）。

3. 误删锁问题#

• 问题场景：客户端 A 的锁因超时释放，客户端 B 获取锁，A 业务执行完成后执行 DEL，误删 B 的锁；

• 解决方案

  1. 锁值唯一化：用 UUID + 客户端 ID 作为锁值，而非固定值；
  2. 原子释放锁：通过 Lua 脚本先校验锁值是否为自己的，再删除（避免 “校验 + 删除” 非原子）。

4. 锁粒度问题#

• 问题场景：使用全局锁（如 lock:all），所有业务竞争同一把锁，导致并发性能极低；
• 解决方案：按业务维度细化锁粒度（如商品 ID、订单 ID），如 lock:stock:1001（仅锁定 1001 号商品的库存）。

5. Redis 集群脑裂问题#

• 问题场景：Redis 主从集群脑裂，主节点宕机后，从节点升级为主节点，但原主节点仍在处理请求，导致多个客户端获取到锁；

• 解决方案

  1. 使用 Redis Redlock 算法（多实例部署，需过半节点获取锁才算成功）；
  2. 配置 Redis 主从的 min-replicas-to-write 参数，减少脑裂概率。

6. 重入性问题#

• 问题场景：同一客户端获取锁后，再次请求获取锁时失败（非重入锁）；

• 解决方案

  1. 锁值存储 “客户端 ID + 重入次数”，获取锁时若为自己的锁，重入次数 + 1；
  2. 释放锁时重入次数 - 1，仅当次数为 0 时删除锁 Key。

一、先理解：缓存与数据库双写不一致的核心成因#

缓存和数据库双写的核心矛盾是：两个独立存储的写操作无法原子化，常见不一致场景有 2 类：

场景 1：更新操作顺序错误（并发更新）#

假设存在两个请求同时更新同一数据：

• 请求 A：更新数据库 → 删除缓存（正常流程）

• 请求 B：查询缓存（未命中）→ 查询数据库（旧值）→ 写入缓存

• 时序异常：A 更新数据库 → B 查询数据库（旧值）→ A 删除缓存 → B 写入缓存（旧值）

  → 最终缓存是旧值，数据库是新值，不一致。

场景 2：删除 / 更新缓存失败（网络 / 宕机）#

• 请求 A：更新数据库成功 → 删除缓存时网络超时 / Redis 宕机 → 缓存未删除

  → 后续查询会读取缓存中的旧值，不一致。

场景 3：并发读写#

• 请求 A：读取缓存（未命中）→ 查询数据库（旧值）

• 请求 B：更新数据库（新值）→ 删除缓存

• 时序异常：A 查询数据库（旧值）→ B 更新数据库 + 删除缓存 → A 写入缓存（旧值）

  → 缓存存旧值，数据库存新值。

方案 1：延时双删（最简单，适配大部分场景）#

1
graph TD
2
    A[收到更新请求] --> B[更新数据库]
3
    B --> C[第一次删除缓存]
4
    C --> D[延时N毫秒（如500ms）]
5
    D --> E[第二次删除缓存]
6
    E --> F[操作完成]

1
@Service
2
public class UserService {
3
    @Resource
4
    private UserMapper userMapper;
5
    @Resource
6
    private StringRedisTemplate redisTemplate;
7
    // 延时时间（根据业务QPS调整，建议500ms~1s）
8
    private static final long DELAY_TIME = 500;
9

10
    public void updateUser(User user) {
11
        // 1. 更新数据库
12
        userMapper.updateById(user);
13
        String cacheKey = "user:" + user.getId();
14

15
        // 2. 第一次删除缓存
16
        redisTemplate.delete(cacheKey);
17

18
        // 3. 延时后第二次删除（异步执行，避免阻塞主线程）
19
        CompletableFuture.runAsync(() -> {
20
            try {
21
                Thread.sleep(DELAY_TIME);
22
                redisTemplate.delete(cacheKey);
23
            } catch (InterruptedException e) {
24
                Thread.currentThread().interrupt();
25
            }
26
        });
27
    }
28
}

方案 2：缓存更新 + 分布式锁（强一致性，适配高并发写）#

1
graph TD
2
    A[收到更新请求] --> B[获取分布式锁（key=user:{id}）]
3
    B --> C{获取锁成功？}
4
    C -- 否 --> D[重试/返回失败]
5
    C -- 是 --> E[更新数据库]
6
    E --> F[更新缓存（设置过期时间）]
7
    F --> G[释放分布式锁]
8
    G --> H[操作完成]
9

10
    I[收到查询请求] --> J[查询缓存（命中则返回）]
11
    J --> K{缓存命中？}
12
    K -- 是 --> L[返回数据]
13
    K -- 否 --> M[获取分布式锁]
14
    M --> N{获取锁成功？}
15
    N -- 否 --> O[重试查询缓存/返回降级数据]
16
    N -- 是 --> P[查询数据库]
17
    P --> Q[写入缓存（设置过期时间）]
18
    Q --> R[释放锁]
19
    R --> L

1
public void updateUserWithLock(User user) {
2
    String lockKey = "lock:user:" + user.getId();
3
    String cacheKey = "user:" + user.getId();
4
    // 1. 获取分布式锁（超时时间30s，避免死锁）
5
    Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 30, TimeUnit.SECONDS);
6
    if (Boolean.TRUE.equals(locked)) {
7
        try {
8
            // 2. 更新数据库
9
            userMapper.updateById(user);
10
            // 3. 更新缓存（设置过期时间，兜底）
11
            redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(user), 1, TimeUnit.HOURS);
12
        } finally {
13
            // 4. 释放锁
14
            redisTemplate.delete(lockKey);
15
        }
16
    } else {
17
        // 获取锁失败，重试（或抛出异常）
18
        throw new RuntimeException("更新频繁，请稍后再试");
19
    }
20
}

方案 3：基于 binlog 的缓存更新（最终一致性，无侵入）#

1
graph TD
2
    A[业务服务更新数据库] --> B[MySQL写入binlog]
3
    B --> C[Canal 监听binlog并解析]
4
    C --> D[判断操作类型（增/删/改）]
5
    D --> E{操作类型}
6
    E -- 改/删 --> F[删除对应缓存]
7
    E -- 增 --> G[写入缓存]
8
    F --> H[操作完成]
9
    G --> H

方案 4：分布式事务（极致一致性，适配金融级场景）#

1. 缓存设置过期时间（兜底）#

所有缓存都必须设置过期时间（如 1 小时），即使出现不一致，过期后也会自动失效，重新从数据库加载最新值。

2. 读写分离场景的特殊处理#

若数据库是读写分离架构，需注意：

• 更新操作走主库，查询操作若缓存未命中，需查主库（避免从库同步延迟导致的旧值）；
• 或等待从库同步完成后再写入缓存。

3. 避免缓存更新，优先删除缓存#

“更新缓存” 易出现并发问题，建议优先选择 “删除缓存”—— 查询时缓存未命中，再从数据库加载最新值写入，减少不一致概率。