推荐用base64url编码6字节随机数生成短码，冲突概率低且不可预测；需先EXISTS校验再写入，跳转用Lua脚本原子读URL并INCR计数，Redis用String类型存short:{code}→URL，设EX过期，stat:{code}单独存访问量。
短链接ID怎么生成才不容易冲突
直接用自增ID或时间戳做短码，线上一并发就重复或可预测。真正能用的方案得兼顾唯一性、不可猜测、长度可控。
- 推荐用
base64url编码后的随机字节（如 6 字节 → 约 8 个字符），冲突概率极低，且无序 - 避免用
Math.random()或简单哈希（如MD5(url).substr(0,6)），前者不安全，后者易碰撞且 URL 稍微变动就失效 - 生成后务必先
EXISTS short:abc123检查是否已存在，冲突时重试——别省这一步，否则写入覆盖会导致跳转错乱
String 类型存什么、怎么设过期
Redis 的 SET 命令足够支撑短链映射，但字段设计和过期策略直接影响运维成本和一致性。
- Key 用
short:{code}（如short:xyz789），Value 存原始 URL，纯字符串，不 JSON 化——没必要，还占空间 - 必须加
EX过期时间，比如SET short:xyz789 "https://example.com/long?x=1" EX 3600，防止垃圾数据堆积 - 别依赖业务层“定时清理”，Redis 自带过期机制更可靠；但注意：过期是惰性+定期混合删除，大量过期 key 可能引发延迟毛刺
跳转时如何原子读取并计数
用户点击短链，既要读出目标 URL，又想统计访问次数——两个操作不能分开做，否则并发下计数会丢。
- 用
GET+INCR组合不行：中间可能被删或过期，GET返回空后INCR还在执行 - 正确做法是 Lua 脚本保证原子性：
if redis.call("EXISTS", KEYS[1]) == 1 then local url = redis.call("GET", KEYS[1]) redis.call("INCR", "stat:" .. KEYS[1]) return url else return nil end -
stat:short:xyz789单独存计数，别和跳转 URL 混在一个 key 里——类型不同、生命周期不同、查询场景也不同
为什么不用 Hash 或 Sorted Set 存短链
有人想把 URL、创建时间、访问数全塞进一个 HASH，看起来“结构清晰”，实际徒增复杂度。
-
HASH无法设置整体 TTL，只能给每个 field 单独设，而 Redis 不支持 field 级过期——结果就是 URL 过期了，访问数还挂着 -
ZSET更没必要：短链跳转不需要排序或范围查询，引入 score 只是增加写开销和理解成本 - String 是最轻量、最直接、TTL 最干净的载体，别为“看起来更规范”牺牲可维护性
