Redis缓存击穿与分布式锁实战：专栏目录、源码与实验说明
热门商品缓存一过期，为什么几十个请求会同时回源？加了本地锁后，部署两个实例为什么仍会查两次数据库？Redisson看门狗会不会保证业务永远只有一个执行者？这套三篇实战用同一个可运行工程逐步回答。
从哪里开始
- 缓存击穿：热点缓存失效后的重建流程：先复现重复回源，再用本地锁、锁内二次检查和回填顺序减少查询。
- Redis分布式锁：租期、误删保护与原子回填：验证SET NX、TTL、唯一token、Lua比较删除和旧持有者回填。
- Redisson：看门狗续期与故障验证：区分显式租期和自动续期，观察业务进程退出、Redis不可用的行为。
专栏主页。本页免费，三篇实战设置为VIP可见；文章及资源的最终可用状态以平台审核结果为准。
一套工程，五组对照
固定环境为Java 21、Spring Boot 3.4.4、Redis 7.4.2、Redisson 3.45.1。商品1001来自真实H2表；两个独立JVM各持一份相同的只读数据，共享Redis。每次查询额外等待300毫秒，只为了扩大并发窗口。
| 方案 | 实例数 | 三轮每轮32并发的数据库查询次数 |
|---|---|---|
| 无保护 | 1 | 32 / 32 / 32 |
| 本地锁 | 1 | 1 / 1 / 1 |
| 本地锁 | 2 | 2 / 2 / 2 |
| Redis租期锁 | 2 | 1 / 1 / 1 |
| Redisson | 2 | 1 / 1 / 1 |
本次480次冷请求、120次热请求全部正确，54项断言通过。原始报告同时保留逐请求耗时、查询计数、TTL和竞争者结果。人工延迟、本机调度和独立H2副本决定了这些结果只能用来研究机制，不能代表生产MySQL容量或吞吐量。
源码和报告怎么获取
下载完整源码与实验报告（VIP专享资源）。资源已上传，当前待审核；上传页面提示审核可能需要2至20个工作日，审核通过前无法保证下载可用。请先确认页面状态再决定是否获取会员。
压缩包包含Java工程、Maven配置、Redis准备脚本、Python实验脚本、三章正文、README和JSON原始报告，不含第三方二进制。需要联网下载Maven依赖，并准备JDK21、Maven、Python3和可执行Redis。
运行入口：
bash
mvn -s maven-settings.xml package
bash experiments/setup_redis.sh
python3 experiments/run.py --rounds 3 --requests 32脚本只连接127.0.0.1，启动自己独占的Redis及两个应用，最后清理本次创建的进程。故障实验会终止脚本自己创建的应用进程及Redis，请在独立实验环境中运行。
适合谁，能解决什么
适合已经会写Spring Boot接口、了解Redis基本命令，并希望亲自验证锁行为的Java开发者。阅读顺序建议为缓存击穿、原生Redis锁、Redisson。每章都有现象、代码、验证步骤、实测结果与练习，不需要先读完其他系列。
本套聚焦只读商品缓存重建，未验证Redis主从切换、Cluster、网络分区与生产写入事务。涉及扣库存、转账、发券时，仍需根据受保护资源设计幂等、版本校验或fencing机制。不要把缓存实验结论直接当成资金业务保证。
这是当前已完成的三篇实战，不对尚未发布的章节作交付承诺。正文基于作者既有文章重新组织，示例工程与脚本独立补齐，部分文字由AI辅助整理。欢迎在文章评论中附上环境、命令和脱敏错误信息，讨论复现实验中遇到的问题。