Redis on 吾爱主机

Redis 分布式锁：互斥、安全释放与续期工程实践

Thu, 30 Jul 2026 00:00:00 +0800

下单扣库存、定时任务防重、接口幂等窗口、分片任务抢占——多进程/多实例同时触达同一共享资源时，都需要互斥。本地 synchronized 或 Mutex 只覆盖本机；跨进程时，工程上常见做法是把锁状态放到 Redis 这类高可用共享存储里。

本文依据 Redis 官方 Distributed Locks with Redis、SET 命令文档（含 Patterns）、Scripting with Lua 与 GETDEL 说明，把单实例正确加解锁、误删他人锁、主从异步复制下的安全边界、锁续期，以及 Redlock/fencing token 的工程取舍讲清楚，并给出可复现命令实验与排错清单。它和本站「缓存穿透/击穿/雪崩」互补：那篇讲缓存一致性与流量保护，本篇讲跨实例互斥原语本身。

一、问题背景：分布式互斥要什么

官方把有效的分布式锁最小保证概括为三条（Safety / Liveness）：

属性	含义	工程直觉
互斥（Safety）	任意时刻最多一个客户端持有锁	两台机器不能同时“以为自己锁住了”
无死锁（Liveness A）	持锁客户端崩溃或分区后，锁最终可被再次获取	必须有 TTL / 自动释放
容错（Liveness B）	多数 Redis 节点存活时仍可加解锁（面向 Redlock 场景）	单点故障与多数派策略

只满足“看起来能 SET 成功”不够。真正会在生产踩雷的，通常是：

加锁非原子：SETNX 成功后再 EXPIRE，进程在中间崩溃 → 永久锁死；
解锁不安全：业务超时后锁已过期被别人抢走，本客户端仍 DEL → 删掉别人的锁；
无 token 签名：所有客户端写同一个固定 value，无法判断“这把锁还是不是我的”；
把主从 failover 当强一致：异步复制下会出现双持锁窗口。

二、核心机制：单实例正确加解锁

2.1 原子加锁：`SET key token NX PX ttl`

官方单实例推荐写法（毫秒 TTL 示例）：

SET resource_name my_random_value NX PX 30000

对应语义（见 SET 文档）：

选项	作用
`NX`	仅当 key 不存在时才设置
`PX milliseconds`	以毫秒设置过期（也可用 `EX seconds`）
value = 随机 token	标识“这把锁属于哪个客户端/哪次加锁”

SET 成功返回 OK 表示抢到锁；key 已存在时（NX 条件不满足）返回空，表示未抢到。NX 与过期时间在同一条命令里完成，避免“加锁成功但没 TTL”的经典坑。

SET 文档的 Patterns 小节也写了同类形态：

SET resource-name anystring NX EX max-lock-time

并强调：简单 DEL 解锁可工作，但更稳健的做法是 token + 条件删除。

2.2 为什么 value 必须是随机 token

官方要求 value 在所有客户端、所有加锁请求间唯一。建议量级约 20 字节随机（如 /dev/urandom）；也可用“微秒时间戳 + 客户端 ID”等折中方案（安全性略弱，但多数场景够用）。

token 的唯一用途：解锁时证明“我仍是当前持有者”，避免过期后误删他人锁。

2.3 安全解锁：条件删除，而不是裸 `DEL`

错误写法：

DEL resource_name

时序灾难：

客户端 A 加锁，TTL = 30s；
A 业务卡住超过 30s，key 过期；
客户端 B 成功 SET NX 拿到同一资源；
A 恢复后执行 DEL → B 的锁被删掉，C 又能进入临界区。

官方正确路径有两层：

（1）Redis 8.4+：DELEX 条件删除（文档写法）

DELEX key IFEQ my_random_value

（2）更通用：Lua 脚本（8.4 之前也适用）

if redis.call("get", KEYS[1]) == ARGV[1] then
 return redis.call("del", KEYS[1])
else
 return 0
end

调用形态：

EVAL "<script>" 1 resource_name token-value

GET 比较与 DEL 在脚本内完成。官方 Scripting with Lua 明确：脚本在服务器侧原子执行，执行期间阻塞其他活动——这对“校验 token 再删除”至关重要，客户端侧的 GET + DEL 两步命令不是安全等价物。

注意：GETDEL 会“读出并删除”，但它不校验 token，不能单独当作安全解锁命令。

2.4 锁有效期（lock validity time）的双重含义

TTL 既是：

自动释放时间（持锁者崩溃后的死锁自愈）；
持锁者必须在此窗口内完成工作的时间预算。

互斥保证是时间窗口内的互斥，不是“进程活着就永远持锁”。业务若可能超过 TTL，要么加大合理 TTL，要么做续期，并在业务层准备好超时后的幂等/回滚。

三、主从复制为什么不够“天然安全”

单实例方案在“偶尔双持可接受”的业务里很实用；但若把 Redis 主从 + 自动 failover 当成强一致锁，会踩官方点名的竞态：

客户端 A 在 master 上拿到锁；
master 在把该写复制到 replica 前崩溃；
replica 升主；
客户端 B 在新 master 上再次 SET NX 成功 → Safety 被破坏。

原因：Redis 复制默认是异步的。官方态度很务实：若故障场景下短暂双持可接受，复制方案可用；否则应认真评估 Redlock 或更强的一致性组件，并在业务侧使用 fencing token。

四、Redlock 概要：多数派 + 耗时校验

Redlock 假设有 N 个独立 Redis master（示例 N=5，互不依赖复制协调）。客户端流程：

记录当前毫秒时间戳 T1；
用相同 key 与相同随机 value，在 N 个实例上并行 SET ... NX PX；对每个实例使用远小于锁 TTL 的连接/命令超时（例如 TTL=10s 时超时约 5–50ms），避免卡在不可用节点上；
计算耗时 elapsed = now - T1；仅当在多数实例（至少 N/2+1）加锁成功，且 elapsed < TTL 时，才认为获得锁；
有效剩余时间约为 TTL - elapsed（再扣一点时钟漂移余量）；
若失败：对所有实例尝试解锁（包括“以为没锁上”的），尽快释放部分锁。

失败重试应加随机退避，降低多客户端同时抢锁导致的“脑裂式空转”。释放时无论是否自认成功，都应尝试释放，降低依赖 TTL 的可用性惩罚。

4.1 续期（lock extension）

若工作可拆成小步骤，可用较短默认 TTL，并在接近过期时向多数实例发送 Lua：

仅当 key 存在且 value 仍是自己的 token 时，延长 TTL；
仅当多数实例续期成功且仍在有效时间内，才认为续期成功；
必须限制最大续期次数，否则可能破坏 liveness（锁永远被同一客户端拖住）。

这与许多客户端库里的 “watchdog / lock watchdog” 思路一致：续期是持锁期间的重新确认，不是“进程活着就一定安全”。

4.2 时钟与一致性免责声明（官方 disclaimer）

官方在文档末尾明确提醒：

若关心正确性，应实现 fencing tokens；不要假设“进程还活着 = 锁一定还在”；
Redis TTL 不依赖单调时钟，墙钟跳变理论上可能导致异常；应规范运维（避免手工乱改时间、正确配置 NTP），但仍不能把时钟理想化。

Martin Kleppmann 对 Redlock 的分析与 antirez 的回应均被官方列入阅读清单——工程选型时请当作必读辩论，而不是站队口号。

五、工程增强：Fencing Token 与临界区设计

即使锁服务偶发双持，业务仍可把破坏降到最低：

Fencing token：每次成功加锁从单调递增源（DB 序列、强一致元数据服务等）取一个 token；写共享资源时带上该 token；资源端拒绝小于已接受 token 的写。这样后拿到“旧锁”的客户端写不进去。
临界区尽量短：锁内只做“决策 + 提交意图”，重 IO 放到锁外并用幂等键保护。
业务幂等：以订单号、任务 ID、版本号做天然去重，锁失败/超时可安全重试。
可观测性：记录加锁耗时、失败原因、续期次数、解锁脚本返回 0 的次数（token 不匹配）。

六、可复现实验（单实例）

下面用 redis-cli 演示互斥、过期与误删防护。假设本地 6379 有 Redis。

6.1 互斥：第二个客户端抢不到

# 终端 A：抢锁
redis-cli SET lock:order:1001 "token-A-111" NX PX 15000
# 期望：OK

# 终端 B：同 key 再抢
redis-cli SET lock:order:1001 "token-B-222" NX PX 15000
# 期望：(nil) —— NX 失败

redis-cli GET lock:order:1001
# 期望：token-A-111
redis-cli PTTL lock:order:1001
# 期望：正数毫秒

6.2 安全解锁 vs 危险 `DEL`

# 正确：仅 token 匹配才删
redis-cli EVAL 'if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end' 1 lock:order:1001 token-A-111
# 期望：1

# 再抢，模拟 B 持锁
redis-cli SET lock:order:1001 "token-B-222" NX PX 15000

# A 拿着过期旧 token 误删：应失败
redis-cli EVAL 'if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end' 1 lock:order:1001 token-A-111
# 期望：0 —— 不会删掉 B 的锁

redis-cli GET lock:order:1001
# 期望：仍是 token-B-222

6.3 续期：仅持有者可延长

redis-cli SET lock:job:9 "token-C" NX PX 5000

# 错误 token 续期（应不改 TTL / 不改 value）
redis-cli EVAL 'if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("pexpire", KEYS[1], ARGV[2]) else return 0 end' 1 lock:job:9 wrong-token 20000
# 期望：0

# 正确 token 续期
redis-cli EVAL 'if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("pexpire", KEYS[1], ARGV[2]) else return 0 end' 1 lock:job:9 token-C 20000
# 期望：1
redis-cli PTTL lock:job:9
# 期望：接近 20000ms

6.4 伪代码骨架（语言无关）

import secrets, time

def acquire(r, key, ttl_ms=30000, retry=3, backoff=0.05):
 token = secrets.token_hex(16)
 for _ in range(retry):
 if r.set(key, token, nx=True, px=ttl_ms):
 return token
 time.sleep(backoff)
 return None

UNLOCK_LUA = """
if redis.call("get", KEYS[1]) == ARGV[1] then
 return redis.call("del", KEYS[1])
else
 return 0
end
"""

def release(r, key, token):
 return r.eval(UNLOCK_LUA, 1, key, token)

def with_lock(r, key, fn, ttl_ms=30000):
 token = acquire(r, key, ttl_ms=ttl_ms)
 if not token:
 raise RuntimeError("lock not acquired")
 try:
 return fn(token) # 可把 token 当作 fencing 的一部分上送
 finally:
 release(r, key, token)

生产中请再补：续期协程/线程、最大持锁时间、指标与超时取消。

七、常见坑与排查清单

现象	可能原因	排查/修复
锁永远解不开	只 `SETNX` 未设过期；或 TTL 极大	统一 `SET NX PX`；审计历史 key
偶发并发进入临界区	解锁用了裸 `DEL`；或业务超时后无 fencing	Lua/`DELEX IFEQ`；加 fencing token
故障切换后双写	依赖异步主从当强一致锁	评估是否可接受；否则 Redlock/外部强一致 + fencing
加锁抖动高	固定重试无退避；热点锁竞争	随机退避 + 缩短临界区 + 锁粒度拆分
续期把锁续成“永不释放”	无限 watchdog	上限次数/墙钟最大持锁时间
集群下 Lua 访问了未声明的 key	违反脚本 key 规则	所有 key 经 `KEYS` 传入；遵循 Cluster 槽约束
以为 `GETDEL` 能安全解锁	`GETDEL` 不校验 owner	必须条件删除

八、选型建议（务实版）

单机房、可接受极低概率异常双持、业务幂等完善：单 Redis + SET NX PX + token Lua 解锁通常足够，实现简单、延迟低。
对互斥更敏感、可运维多实例独立 Redis：评估 Redlock 及成熟库（官方文档列出 Redisson、Redsync、node-redlock 等），并读完 Kleppmann/antirez 讨论。
金融级强一致临界区：不要只靠 Redis TTL 语义；优先考虑带 fencing 的共识/事务系统，Redis 锁最多做“快速失败的互斥提示”。
任何方案：临界区短、幂等、可观测、可回滚，比纠结算法名词更重要。

九、总结

分布式锁的底线是 互斥 + 可自动释放 + 安全解锁。
单实例正确骨架：SET key token NX PX ttl + token 条件删除（Lua 或 Redis 8.4 DELEX IFEQ）。
裸 DEL、拆分的 SETNX+EXPIRE、固定 value，是三大经典错误。
异步主从 failover 不能保证互斥；是否可接受取决于业务与是否有 fencing。
Redlock 用多数派与耗时校验提升容错，但涉及时钟漂移、持久化/延迟重启与社区争议——官方自己要求你读分析文章。
工程上把锁当作辅助互斥，用 fencing token、幂等与短临界区兜底正确性。

参考资料

Redis 官方文档：Distributed Locks with Redis（含单实例实现、Redlock、续期、disclaimer）
https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/
Redis 命令：SET（NX / PX / EX 与 Patterns 中的加解锁说明）
https://redis.io/docs/latest/commands/set/
Redis 官方文档：Scripting with Lua（脚本原子执行、EVAL/KEYS/ARGV）
https://redis.io/docs/latest/develop/programmability/eval-intro/
Redis 命令：GETDEL（读删一体，但不替代 token 校验解锁）
https://redis.io/docs/latest/commands/getdel/
Redis 文档源码（可检索原文）：distributed-locks markdown
https://raw.githubusercontent.com/redis/docs/main/content/develop/clients/patterns/distributed-locks.md
Martin Kleppmann：How to do distributed locking（Redlock 分析，官方文末引用）
https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
antirez：Is Redlock safe?（对上述分析的回应，官方文末引用）
http://antirez.com/news/101

Redis 缓存穿透、击穿与雪崩：原理、场景与工程解法

Mon, 13 Jul 2026 00:00:00 +0800

在高并发系统里，Redis 常常被放在数据库前面做读加速。一旦缓存设计不当，问题往往不是“Redis 慢一点”，而是数据库被瞬间打穿。工程上最常见、也最容易被混为一谈的三类故障是：缓存穿透、缓存击穿和缓存雪崩。

这三类问题听起来相似，根因却不同：

问题	典型特征	直接伤害
缓存穿透	查的是不存在的数据，缓存和 DB 都没有	恶意或异常请求反复打到 DB
缓存击穿	某个热点 key 刚好过期	同一时刻大量请求打到 DB
缓存雪崩	大量 key 同时失效，或缓存层整体不可用	系统级读流量直接压垮 DB

本文从现象、根因、可落地方案三层拆开，并结合 Redis 官方能力（SET 的 NX/EX、EXPIRE、淘汰策略、分布式锁模式）给出可复用实践。

一、先把请求路径画清楚

一个典型读路径是：

Client -> App -> Redis -> (miss) -> Database -> write back Redis -> response

缓存层的价值在于：

把高频读从数据库剥离出来；
用更低延迟响应热点数据；
给数据库争取容量和稳定性。

因此，任何“绕过缓存直接打 DB”的路径，都要被当成故障设计点来处理。

二、缓存穿透：查不存在的数据

1. 现象

请求的 key 在业务上不存在，例如：

用户 ID -1
商品 ID 999999999
被爬虫扫出来的非法参数

此时 Redis 没有缓存，数据库也查不到记录。如果应用只在“查到结果时才写缓存”，那么每次请求都会落到数据库。

2. 根因

穿透的本质不是“缓存过期”，而是：

空结果没有被负缓存（negative caching）保护。

3. 解法

方案 A：缓存空对象（最常用）

查库为空时，也写入一个短 TTL 的空值标记：

# 伪命令：空结果缓存 60 秒
SET product:999999999 __NULL__ EX 60

应用读到 __NULL__ 时直接返回“不存在”，不再访问数据库。

注意：

TTL 不要太长，避免真实数据刚创建后长时间读不到；
空值要有统一约定，避免和正常业务值冲突；
对写路径做缓存失效/更新，保证最终一致。

方案 B：布隆过滤器（Bloom Filter）前置拦截

对“可能存在”的 ID 集合做布隆过滤器：

数据写入时同步/异步加入过滤器；
查询前先判断“一定不存在还是可能存在”；
一定不存在则直接拒绝，不打 Redis/DB。

适合海量 ID、爬虫扫描、开放查询接口。代价是：

有极低误判率（把不存在判断成可能存在）；
需要维护过滤器更新与扩容。

方案 C：参数与权限校验前置

很多穿透其实是脏流量：

非数字 ID
超范围分页
未登录却访问私有资源

在网关/应用入口直接拦截，比把压力交给缓存更划算。

三、缓存击穿：热点 key 刚好失效

1. 现象

某个非常热的 key（首页配置、秒杀库存视图、热门商品详情）在某一瞬间过期。
下一毫秒，成千上万请求同时看到 miss，一起去查数据库，形成“单点热点打穿”。

2. 根因

击穿关注的是：

单个热点 key 过期窗口内的并发回源。

它和穿透不同：数据本来存在，只是缓存刚好空了。

3. 解法

方案 A：互斥重建（singleflight / 分布式锁）

只有一个请求负责回源重建，其他请求等待或短暂失败重试。

Redis 官方 SET 支持原子条件写入，可用 NX + EX 做互斥：

# 抢重建锁，5 秒自动过期，防止进程崩溃后死锁
SET rebuild:lock:product:1001 1 NX EX 5

流程：

读缓存 miss；
SET lock NX EX 抢锁；
抢到锁的请求查 DB，写回缓存，释放锁；
没抢到锁的请求短暂 sleep/重试读缓存，或返回旧兜底。

官方文档明确：SET key value NX EX seconds 是设置值并带过期时间的常用原子写法；SETNX 在新代码中更推荐用 SET ... NX 替代。

方案 B：逻辑过期（logical expire）

缓存 value 内嵌业务过期时间，物理 key 不过期或过期很久：

{
 "data": {"id": 1001, "price": 99},
 "expireAt": 1720857600
}

读取时：

未逻辑过期：直接返回；
已逻辑过期：返回旧数据，同时异步触发重建。

优点是用户几乎无感 miss；代价是要接受短暂脏读，并做好异步重建失败补偿。

方案 C：热点 key 永不过期 + 主动更新

对真正的超级热点，不依赖 TTL 被动失效，而由写路径/定时任务主动更新。
TTL 更适合普通数据；热点数据更适合“写时更新 + 监控”。

四、缓存雪崩：大面积失效或缓存层故障

1. 现象

两类雪崩最常见：

过期雪崩：大量 key 在同一时间点过期；
可用性雪崩：Redis 集群故障、网络分区、连接打满，导致缓存层整体不可用。

结果都是数据库在短时间内接到远超容量的读请求。

2. 根因

雪崩的核心不是某一个 key，而是：

缓存保护面在同一时间失效，流量失去缓冲层。

3. 解法

方案 A：TTL 加随机抖动

不要让同类数据使用完全相同的过期时间：

ttl = base_ttl + random(0, jitter)
# 例如 3600 + random(0, 300)

这样可以把过期曲线打散，避免整点集体回源。

方案 B：多级缓存与本地缓存

本地 Caffeine/Guava Cache 挡住进程内重复读；
Redis 作为分布式缓存；
DB 作为最终数据源。

本地缓存 TTL 更短，可显著降低 Redis 抖动对 DB 的传导。

方案 C：限流、熔断、降级

缓存层异常时，应用不能无脑回源：

对回源 QPS 做令牌桶/漏桶限流；
数据库错误率升高时熔断；
非核心接口返回兜底页/默认配置；
核心读接口优先返回短暂旧数据。

方案 D：正确使用 Redis 内存淘汰策略

当 Redis 用作缓存时，官方建议配置最大内存和淘汰策略，以便内存触顶时按策略驱逐 key，而不是写失败或无规划崩溃。常见策略包括：

allkeys-lru / allkeys-lfu：在全部 key 中淘汰；
volatile-lru / volatile-lfu / volatile-ttl：只在设置了过期时间的 key 中淘汰。

关键点：

缓存场景应显式设置 maxmemory；
按业务选择 LRU/LFU；
监控 evicted_keys、命中率、内存使用，避免“默默淘汰关键数据”却无人知晓。

淘汰策略解决的是内存压力下的可持续性，不能替代业务层的穿透/击穿防护，但能降低缓存层自身失控概率。

五、一套可落地的组合策略

真实系统很少只选一种方案，更常见的是分层组合：

1. 入口校验：挡住非法参数
2. 布隆过滤器/存在性索引：挡住明显不存在的 key
3. Redis 读：命中则返回
4. miss 时：
 - 热点 key：互斥重建或逻辑过期
 - 普通 key：允许有限并发回源
5. DB 空结果：写短 TTL 空缓存
6. DB 有结果：写缓存，TTL 加抖动
7. 全链路：限流 + 熔断 + 监控告警

伪代码示例

def get_product(product_id: str):
 if not valid_id(product_id):
 return None

 if bloom and not bloom.might_contain(product_id):
 return None

 cached = redis.get(f"product:{product_id}")
 if cached == "__NULL__":
 return None
 if cached is not None:
 return decode(cached)

 # 热点互斥重建
 locked = redis.set(f"rebuild:lock:product:{product_id}", "1", nx=True, ex=5)
 if not locked:
 time.sleep(0.05)
 return get_product(product_id) # 简化：重试读缓存

 try:
 row = db.query_product(product_id)
 if row is None:
 redis.set(f"product:{product_id}", "__NULL__", ex=60)
 return None
 redis.set(f"product:{product_id}", encode(row), ex=3600 + random.randint(0, 300))
 return row
 finally:
 redis.delete(f"rebuild:lock:product:{product_id}")

说明：

SET ... NX EX 用于短锁，避免击穿时并发回源；
空值缓存用于防穿透；
TTL 抖动用于打散过期，降低雪崩概率。

六、排查清单：线上怎么快速判断是哪一种

1. 先看指标

Redis 命中率是否骤降
Redis 连接数/超时是否升高
数据库 QPS、慢查询、连接池是否打满
是否集中在某几个 key，还是大面积 key

2. 判断路径

观察	更可能是
大量非法/不存在 ID，DB 查空很多	穿透
单个热 key 流量尖峰，过期瞬间 DB 飙升	击穿
整点或批次任务后大面积 miss	过期雪崩
Redis 超时/主从切换/集群异常同时发生	可用性雪崩

3. 临时止血

对异常查询参数限流；
对热点 key 预热并临时延长 TTL；
打开空值缓存；
给 DB 回源加总开关/配额；
非核心读降级。

七、设计原则总结

缓存不是数据库的影子，是保护层。 任何 miss 路径都要有预算。
空结果也是结果。 不做负缓存，就容易被穿透。
热点不能靠“碰巧没过期”。 要有互斥重建、逻辑过期或主动更新。
过期时间要工程化。 相同 TTL 是雪崩温床，抖动是基本操作。
缓存故障要有降级。 没有限流和熔断的缓存架构，只是把风险延后到数据库。
可观测性比“感觉很快”更重要。 命中率、回源 QPS、淘汰数、锁竞争都要可监控。

八、什么时候不该过度设计

不是所有系统都要上布隆过滤器 + 逻辑过期 + 多级缓存：

读 QPS 不高、数据几乎都存在：做好空值缓存和基础 TTL 即可；
写极少、读极多的配置类数据：适合主动更新 + 较长 TTL；
强一致要求极高的余额/库存：缓存只能做辅助，核心以数据库/专用组件为准，并明确一致性模型。

架构选择应匹配流量模型和一致性要求，而不是堆名词。

总结

缓存穿透、击穿、雪崩并不是三个神秘黑话，而是三条清晰的失败路径：

穿透：不存在的数据反复打穿 DB；
击穿：热点 key 失效瞬间被并发打穿；
雪崩：保护面大面积失效，流量失去缓冲。

把问题定义清楚后，解法会自然收敛到：入口校验、空值缓存、互斥重建、TTL 抖动、淘汰策略、限流熔断与监控。
Redis 提供了 SET NX/EX、EXPIRE、内存淘汰和分布式锁模式等基础能力，但真正决定系统稳不稳的，是你有没有把这些能力嵌进完整的读路径设计里。

参考资料

Redis 官方文档：SET 命令（含 NX / EX 等选项）
Redis 官方文档：EXPIRE 命令
Redis 官方文档：SETNX 命令
Redis 官方文档：Key eviction 内存淘汰策略
Redis 官方文档：Distributed locks 分布式锁模式

Spring Data 2025.0.13 收官发布：3.5.x 项目升级与迁移检查清单

Wed, 01 Jul 2026 01:15:51 +0000

Spring Data 2025.0.13 已经发布。对还在 Spring Boot 3.5.x / Spring Data 3.5.x 线上分支上的团队来说，这不是一个“追新功能”的版本，而更像一次收尾性质的维护窗口：官方发布说明明确提到，2025.0.13 是 Spring Data 3.5.x generation 预期的最后一个开源服务版本，并且只包含回归修复。换句话说，如果你的系统还停留在这一代，短期内应该尽快吸收这个补丁；中期则应该把迁移到 2025.1.x / 4.x 系列纳入排期。

本文用工程实践的角度梳理：这次发布意味着什么、哪些模块值得重点回归、Maven/Gradle 应该怎么升级，以及团队应该怎样规划下一阶段迁移。

这次发布的关键信息

先把核心事实讲清楚：

Spring Data BOM 版本：2025.0.13。
发布时间：GitHub Release 显示为 2026-06-24T07:40:08Z。
发布性质：服务版本，主要面向回归修复。
官方博客说明：它预期是 Spring Data 3.5.x generation 的最后一个开源发布版本。
官方建议：尽早升级到最新的 4.0.x（2025.1.x release train）或 4.1.x release。
Spring 官方博客还说明，Spring Boot 3.5.16 计划在次日拾取这次 Spring Data 发布。

这几个信息放在一起，结论很直接：2025.0.13 适合作为 Spring Boot 3.5.x 项目的稳定补丁基线，但不应该被当作长期停留点。

2025.0.13 包含哪些模块

Spring Data 使用 release train / BOM 管理一组子项目版本。2025.0.13 对应的参与模块包括：

模块	对应版本	常见使用场景
Spring Data Commons	3.5.13	Repository 抽象、分页、排序、映射基础设施
Spring Data JPA	3.5.13	JPA / Hibernate 持久化
Spring Data MongoDB	4.5.13	MongoDB 文档数据库访问
Spring Data Redis	3.5.13	Redis 数据访问与缓存相关集成
Spring Data Cassandra	4.5.13	Cassandra 数据访问
Spring Data Elasticsearch	5.5.13	Elasticsearch 数据访问
Spring Data Couchbase	5.5.13	Couchbase 数据访问
Spring Data Neo4j	7.5.13	图数据库访问
Spring Data REST	4.5.13	Repository REST 暴露
Spring Data Relational	3.5.13	JDBC / R2DBC 等关系型访问基础
Spring Data LDAP	3.5.13	LDAP 数据访问
Spring Data KeyValue	3.5.13	Key-Value 抽象支持

如果你的项目通过 Spring Boot 管理依赖，多数情况下不需要手工声明这些子模块版本；跟随 Spring Boot 3.5.16 或显式导入 spring-data-bom:2025.0.13 即可。

值得关注的修复点

这次发布不是大版本功能升级，重点是降低已知回归风险。官方 Release 中比较值得应用开发团队关注的点包括下面几类。

1. Spring Data Commons：字段解析相关修复

Spring Data Commons 3.5.13 修复了 TypeDiscoverer 在子类字段与父类同名字段场景下的解析问题。Release 描述中提到：

保留子类字段，而不是被父类中被遮蔽的字段覆盖。
修复属性类型从隐藏的父类字段解析，而不是从子类字段解析的问题。

这类问题通常不会影响简单 Entity，但在下面这些场景里更容易踩坑：

领域模型存在继承层次；
子类重新声明了父类中的同名字段；
Repository 查询、投影、映射元数据依赖属性类型推断；
代码生成或历史模型导致字段命名不够干净。

如果你的项目里有复杂继承模型，升级后建议重点跑 Repository 查询、DTO 投影、Example 查询、排序分页与自定义转换器相关测试。

2. Spring Data JPA：JPQL / EQL 单字符字符串解析修复

Spring Data JPA 3.5.13 修复了 JPQL 和 EQL 中集合成员表达式的单字符字符串字面量解析问题。Release 中提到的问题是：单字符字符串字面量作为 MEMBER OF 左操作数时解析失败。

受影响的代码可能长得类似下面这样：

@Query("select u from User u where 'A' member of u.flags")
List<User> findUsersWithFlagA();

实际项目中未必完全使用这个写法，但如果你有：

手写 @Query；
动态拼接 JPQL / HQL；
使用集合属性做成员判断；
查询中存在单字符枚举值或标记值；

就应该把这些查询纳入回归测试。

3. Spring Data JPA：Hibernate 依赖升级

Spring Data JPA 3.5.13 的 Release 还列出了 Hibernate 升级到 6.6.53.Final。这通常是好事，但 ORM 层升级也最容易暴露边界行为差异，例如：

SQL 生成变化；
方言兼容性差异；
延迟加载与关联抓取问题；
Criteria / JPQL 解析差异；
数据库驱动与 Hibernate 方言组合问题。

因此，JPA 项目升级时不要只跑单元测试，最好至少补一轮连接真实数据库的集成测试。

Maven 项目怎么升级

如果你的项目使用 Spring Boot 3.5.x，并通过 spring-boot-starter-parent 管理版本，推荐优先升级 Spring Boot 到包含该 Spring Data 版本的补丁版本，例如 Spring Boot 3.5.16：

<parent>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>3.5.16</version>
 <relativePath/>
</parent>

如果项目不能立刻升级 Spring Boot，但确实需要单独锁定 Spring Data release train，可以在 dependencyManagement 中导入 BOM：

<dependencyManagement>
 <dependencies>
 <dependency>
 <groupId>org.springframework.data</groupId>
 <artifactId>spring-data-bom</artifactId>
 <version>2025.0.13</version>
 <scope>import</scope>
 <type>pom</type>
 </dependency>
 </dependencies>
</dependencyManagement>

不过要注意：Spring Boot 自身也会管理 Hibernate、数据库驱动、Spring Framework 等版本。单独覆盖 Spring Data BOM 虽然可行，但更容易形成“局部升级、整体依赖矩阵未验证”的状态。生产项目优先选择 Spring Boot 补丁版本，通常更稳。

Gradle 项目怎么升级

使用 Spring Boot Gradle 插件的项目，最简单的方式同样是升级 Boot 版本：

plugins {
 id("org.springframework.boot") version "3.5.16"
 id("io.spring.dependency-management") version "1.1.7"
 java
}

如果需要显式导入 Spring Data BOM，可以这样写：

dependencyManagement {
 imports {
 mavenBom("org.springframework.data:spring-data-bom:2025.0.13")
 }
}

升级后建议运行依赖树检查，确认最终解析出来的版本符合预期：

./gradlew dependencyInsight --dependency spring-data-commons --configuration runtimeClasspath
./gradlew dependencyInsight --dependency spring-data-jpa --configuration runtimeClasspath
./gradlew dependencyInsight --dependency hibernate-core --configuration runtimeClasspath

Maven 项目可以用：

./mvnw dependency:tree -Dincludes=org.springframework.data
./mvnw dependency:tree -Dincludes=org.hibernate.orm:hibernate-core

升级前后的回归检查清单

建议把这次升级当作一次低风险但必须验证的维护发布。可以按下面顺序做。

升级前

记录当前 Spring Boot、Spring Data、Hibernate、数据库驱动版本。
确认项目是否手工覆盖过 spring-data-* 或 Hibernate 版本。
找出所有自定义 Repository、@Query、Specification、Querydsl、Criteria 查询。
标记有继承结构的 Entity / Document / Projection。
准备真实数据库或测试容器环境，而不是只跑 mock 测试。

升级后

运行完整单元测试与集成测试。
对核心 Repository 做 CRUD、分页、排序、复杂条件查询回归。
对 JPA 项目检查启动日志中的 Hibernate 版本与 SQL 方言。
对 MongoDB / Redis / Elasticsearch 项目检查连接、序列化与索引相关逻辑。
使用 dependency:tree 或 dependencyInsight 确认没有混入旧版本 Spring Data 模块。
在预发环境跑一轮真实流量或关键任务。

为什么不要长期停留在 2025.0.x

官方已经把 2025.0.13 定位为 3.5.x generation 预期的最后一个开源服务版本，这意味着后续开源补丁会转向更新的 release train。对企业项目来说，这通常带来三个影响：

安全与兼容性窗口变窄：依赖链上的修复会优先进入新分支。
升级跨度变大：越晚迁移到 2025.1.x / 4.x，累计变化越多，单次升级风险越高。
生态同步成本上升：Spring Boot、Spring Framework、Hibernate、数据库驱动、云原生组件都会继续演进。

因此更合理的策略是：

短期：把 3.5.x 项目升级到 2025.0.13 / Boot 3.5.16，拿到最后一批回归修复。
中期：建立 2025.1.x 或 4.x 的兼容性分支，跑依赖树和自动化测试。
长期：把主要业务线迁移到新的 Spring Boot / Spring Data 主线，减少历史分支维护成本。

团队落地建议

如果你负责一个线上 Spring 项目，可以按下面的节奏推进：

先做补丁升级：在当前主线或维护分支升级到 Spring Boot 3.5.16，或至少导入 Spring Data BOM 2025.0.13。
锁定验证范围：重点测试 Repository、JPA 查询、继承模型、MongoDB/Redis 序列化、Elasticsearch 查询。
保留依赖快照：把升级前后的依赖树保存到 CI 产物或变更单，方便排查回滚。
预留迁移分支：不要等到必须升级时才看 2025.1.x / 4.x，提前建分支验证编译、启动和关键链路。
避免局部硬覆盖：除非有明确原因，否则不要长期手工覆盖 Spring Data 子模块版本，让 Spring Boot BOM 统一管理更安全。

小结

Spring Data 2025.0.13 的价值不在于新特性，而在于给 3.5.x generation 一个相对稳妥的收尾版本。对生产系统来说，这类版本往往比“功能发布”更值得及时处理：它能减少已知回归风险，也给后续迁移到 2025.1.x / 4.x 留出缓冲。

如果你的系统还在 Spring Boot 3.5.x，建议尽快完成补丁升级与回归验证；如果你已经准备进入 Spring Boot 4 / Spring Data 4.x 阶段，则可以把 2025.0.13 当作维护分支的最后稳定基线，同时把主要精力放到下一代 release train 的兼容性验证上。

Redis on 吾爱主机

Redis 分布式锁：互斥、安全释放与续期工程实践

一、问题背景：分布式互斥要什么

二、核心机制：单实例正确加解锁

2.1 原子加锁：SET key token NX PX ttl

2.2 为什么 value 必须是随机 token

2.3 安全解锁：条件删除，而不是裸 DEL

2.4 锁有效期（lock validity time）的双重含义

三、主从复制为什么不够“天然安全”

四、Redlock 概要：多数派 + 耗时校验

4.1 续期（lock extension）

4.2 时钟与一致性免责声明（官方 disclaimer）

五、工程增强：Fencing Token 与临界区设计

六、可复现实验（单实例）

6.1 互斥：第二个客户端抢不到

6.2 安全解锁 vs 危险 DEL

6.3 续期：仅持有者可延长

6.4 伪代码骨架（语言无关）

七、常见坑与排查清单

八、选型建议（务实版）

九、总结

参考资料

Redis 缓存穿透、击穿与雪崩：原理、场景与工程解法

一、先把请求路径画清楚

二、缓存穿透：查不存在的数据

1. 现象

2. 根因

3. 解法

方案 A：缓存空对象（最常用）

方案 B：布隆过滤器（Bloom Filter）前置拦截

方案 C：参数与权限校验前置

三、缓存击穿：热点 key 刚好失效

1. 现象

2. 根因

3. 解法

方案 A：互斥重建（singleflight / 分布式锁）

方案 B：逻辑过期（logical expire）

方案 C：热点 key 永不过期 + 主动更新

四、缓存雪崩：大面积失效或缓存层故障

1. 现象

2. 根因

3. 解法

方案 A：TTL 加随机抖动

方案 B：多级缓存与本地缓存

方案 C：限流、熔断、降级

方案 D：正确使用 Redis 内存淘汰策略

五、一套可落地的组合策略

伪代码示例

六、排查清单：线上怎么快速判断是哪一种

1. 先看指标

2. 判断路径

3. 临时止血

七、设计原则总结

八、什么时候不该过度设计

总结

参考资料

Spring Data 2025.0.13 收官发布：3.5.x 项目升级与迁移检查清单

这次发布的关键信息

2025.0.13 包含哪些模块

值得关注的修复点

1. Spring Data Commons：字段解析相关修复

2. Spring Data JPA：JPQL / EQL 单字符字符串解析修复

3. Spring Data JPA：Hibernate 依赖升级

Maven 项目怎么升级

Gradle 项目怎么升级

升级前后的回归检查清单

升级前

升级后

为什么不要长期停留在 2025.0.x

团队落地建议

小结

2.1 原子加锁：`SET key token NX PX ttl`

2.3 安全解锁：条件删除，而不是裸 `DEL`

6.2 安全解锁 vs 危险 `DEL`