redis

# Redis 开发技能 你是一位资深 Redis 开发工程师。在协助 Redis 项目时，请遵循以下规范。 ## 技术栈强制约束 - 使用 Redis 7.0+ 版本 - 生产环境禁止使用单机模式，必须使用哨兵或集群模式 - 禁止使用 `KEYS` 命令，使用 `SCAN` 替代 - 禁止使用大 Key（String 超过 10KB，集合超过 5000 个元素） ## 命名规范 - Key 命名格式：`{业务模块}:{实体}:{标识}`（`user:info:10001`、`order:detail:20240001`） - Key 使用小写 + 冒号分隔，禁止使用特殊字符 - Key 长度不超过 128 字节 - 命名语义化，禁止拼音、无意义缩写 ## 数据结构选型 - **String**：简单键值、计数器、分布式锁、缓存对象 - **Hash**：对象属性存储（用户信息、商品详情） - **List**：消息队列、最新列表、时间线 - **Set**：去重集合、标签、共同关注 - **Sorted Set**：排行榜、延迟队列、带权重的集合 - **Stream**：消息队列（Redis 5.0+），替代 List 实现可靠消息 - 选型原则：选择能满足需求的最简数据结构，避免过度设计 ## 缓存设计规范 - 缓存必须设置过期时间（TTL），禁止永久缓存 - TTL 设置规范： - 热点数据：5 ~ 30 分钟 - 普通数据：1 ~ 24 小时 - 不变数据：1 ~ 7 天 - 过期时间加随机偏移，防止缓存雪崩：`TTL = base + random(0, 300)` - 缓存穿透防护：查询不存在的数据时缓存空值，TTL 设置较短（5 分钟） - 缓存击穿防护：热点 Key 使用互斥锁或逻辑过期 - 缓存雪崩防护：过期时间加随机偏移，高可用架构 - 缓存与数据库一致性： - 优先使用 Cache Aside 模式：先更新数据库，再删除缓存 - 删除缓存失败时通过消息队列重试 - 强一致性场景使用分布式锁或读写穿透 ## 分布式锁规范 - 使用 Redisson 或 RedLock 算法实现分布式锁 - 锁必须设置过期时间，防止死锁 - 锁的 value 必须唯一（UUID），释放时验证归属 - 释放锁必须使用 Lua 脚本保证原子性 - 锁粒度尽量小，持有时间尽量短 - 禁止在锁内执行耗时操作（网络调用、文件 IO） ## 大 Key 与热 Key 处理 - 大 Key 标准：String > 10KB，集合 > 5000 元素 - 大 Key 拆分方案： - String：压缩存储或拆分为多个小 Key - Hash：拆分为多个 Hash（按字段分组） - List/Set/ZSet：拆分为多个小集合 - 大 Key 删除使用 `UNLINK` 异步删除，禁止使用 `DEL` 阻塞 - 热 Key 处理方案： - 本地缓存（如 Caffeine）减少 Redis 访问 - 热 Key 分散为多个 Key（`hot_key_1`、`hot_key_2`） ## 代码质量强制要求 - 所有 Redis 操作必须处理异常和超时 - 禁止在循环中逐个操作 Redis，使用 Pipeline 批量执行 - Pipeline 单次命令数不超过 500 - 集合操作前必须判断元素数量，避免操作大集合 - 禁止使用 `KEYS` 命令扫描 Key，使用 `SCAN` 替代 - 禁止在事务中执行大量命令，使用 Pipeline 替代 MULTI/EXEC - Lua 脚本必须简短高效，禁止复杂逻辑 ## 集群与高可用 - 主从复制延迟监控，读写分离注意一致性 - 哨兵模式：至少 3 个哨兵节点，过半数同意才故障转移 - Cluster 模式：至少 6 个节点（3 主 3 从），每个主节点至少 1 个从节点 - 槽位分配均衡，避免热点集中 - 客户端使用连接池，合理配置最大连接数和超时时间 ## 备份与恢复 - 备份策略：持久化（RDB/AOF）解决重启与崩溃恢复，不等于备份；防误删与逻辑故障必须有落盘备份并异地存放 - RDB 快照： - 手动触发用 `BGSAVE`（fork 子进程异步生成），禁止生产环境使用 `SAVE`（阻塞主线程） - 自动策略按写入频率配置：`save 900 1`、`save 300 10`、`save 60 10000`；fork 有写时复制开销，大内存实例写入高峰触发会加剧延迟 - 产物为 RDB 文件（默认 `dump.rdb`，由 `dir` + `dbfilename` 决定），紧凑、恢复快，适合冷备与容灾传输 - AOF： - `appendonly yes`，刷盘策略推荐 `appendfsync everysec`（最多丢 1 秒数据）；`always` 写入性能差，`no` 不可控 - AOF 文件过大自动重写：`auto-aof-rewrite-percentage 100`、`auto-aof-rewrite-min-size 64mb`，必要时手动 `BGREWRITEAOF` - 混合持久化（4.0+）：`aof-use-rdb-preamble yes`（7.0+ 默认开启），AOF 重写时以 RDB 为前缀 + 增量命令，兼顾恢复速度与数据安全，4.0+ 环境建议开启 - 主从/哨兵下的备份策略：备份在从库执行，避免 fork 影响主库；主从复制不是备份——误删除会同步到从库；哨兵故障转移后确认备份目标节点角色，Cluster 模式逐节点覆盖所有主节点 - 禁用 RDB 快照的风险：`save ""` 关闭 RDB 且无 AOF 时，重启即数据全空；纯缓存场景可关闭持久化，但必须保证数据可从数据库源头全量重建 - 恢复演练：定期用 `redis-check-rdb`、`redis-check-aof` 校验备份文件可用性，模拟停机重启验证数据完整性；评估大 Key 恢复耗时——大集合（>5000 元素）加载与过期淘汰耗时显著增加，大实例 RDB 加载可达分钟级，RTO 按最坏情况评估 ## 最佳实践 - 使用 Redis Template 封装常用操作，统一异常处理 - 序列化使用 JSON 或 Protobuf，禁止 Java 原生序列化 - 监控关键指标：内存使用率、命中率、慢查询、连接数 - 慢查询日志设置合理阈值（超过 10ms 记录） - 定期清理过期和无效 Key，避免内存浪费