结论：用 redis 做短链跳转的主存储 + mysql 做最终落库，是当前 spring boot 生产环境最稳的组合；纯 redis 存储因无持久化、无结构化查询能力、过期依赖手动设置，易导致死链、数据丢失和业务功能缺失。
直接说结论：用 Redis 做短链跳转的主存储 + MySQL 做最终落库，是当前 Spring Boot 生产环境最稳的组合。纯 Redis 存储看似快，但一旦缓存击穿或实例重启，映射关系就丢了——短链变死链。
为什么不能只用 Redis 存短码 → 长链接映射？
常见错误是把所有短链都塞进 Redis 的 String 类型里，靠 GET short_code 直接返回长链接。这在压测时 QPS 看似很高，但实际有三个硬伤：
- Redis 没有过期时间自动清理机制（除非你显式设
EXPIRE），而短链常需支持“7天后过期”，EXPIRE依赖客户端主动触发，容易漏设 - Redis 重启后数据全丢，没做持久化备份的话，线上所有短链瞬间 404
- 无法做点击量统计、来源分析、状态禁用等业务操作——这些必须走结构化查询，
Redis不擅长
跳转请求怎么避免穿透到 MySQL？
核心是两层兜底：先查 Redis，查不到再查 MySQL，查到后立刻回写 Redis 并设置合理过期时间。但要注意两个关键点：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须用
SETNX+EXPIRE原子操作回写缓存，否则高并发下可能写入多个相同短码的冗余缓存 -
expire_time字段要从数据库读出后，再算出剩余秒数传给EXPIRE，不能直接设固定值（比如统一设 24h），否则过期逻辑和业务不一致 - 加一层
BloomFilter（存在 Redis 中）过滤无效短码请求，避免恶意刷不存在的short_code导致缓存雪崩
短码生成时 Redis 怎么防重复？
很多人用 MD5(long_url).substring(0,6)，结果上线三天就撞出重复短码。这不是概率问题，是设计缺陷。正确做法是：
- 生成短码前，先用
EXISTS short_code查 Redis；如果存在，立刻重试——但别盲目循环，最多 3 次，超时走降级（比如返回 HTTP 429） - 不要依赖 URL 内容哈希，而是用分布式 ID（如
snowflake）+Base62.encode()，保证全局唯一且不可预测 - 首次写入 MySQL 成功后，必须同步执行
SET short_code original_url EX 86400，且用pipeline包裹，防止网络中断导致缓存缺失
真正难的不是生成或跳转本身，而是当短码被高频访问时，如何让 GET short_code 始终命中、不抖动、不出错。这要求 Redis 连接池配置合理（max-active=200，min-idle=10），Lettuce 客户端开启 ping-before-activate，还要监控 redis_latency_ms 指标——这些细节一漏，百万 QPS 下延迟就飘到 500ms 以上。
