一、核心设计规范

1. Key 设计规范

• 可读性与结构化
  • 使用业务模块名作为前缀，使用冒号 : 进行层级分隔，形成清晰的命名空间。格式为 业务名:模块名:表名:唯一标识[:子属性]。
  • 例如：live:room:1001:info, order:20241104:2001:status。
• 简洁性
  • 在保证可读性的前提下，Key 应尽量简短，因为 Key 本身也占用内存。但切忌为了简短而牺牲可读性。
• 唯一性
  • 必须能够唯一标识一条数据，避免 Key 冲突。
• 避免特殊字符
  • 不要包含空格、换行、引号等不可见或特殊字符。冒号 : 是公认的标准分隔符。
• 固定格式
  • 团队内部应对 Key 的命名格式达成一致并严格遵守，便于管理和维护。

2. Value 设计规范

• 拒绝大 Key
  • 定义：
    • 字符串（String）类型：Value 大小超过 10KB。
    • 集合类型（Hash, List, Set, ZSet）：元素数量超过 5000（此阈值可根据业务调整，但需明确），或总价值大小过大。
  • 危害：
    • 网络阻塞，请求响应慢。
    • 内存不均，尤其在集群模式下。
    • 执行 DEL、HGETALL 等命令易阻塞 Redis 服务，可能引发雪崩。
  • 规避方法：
    • 拆分：将大 Hash 按字段前缀拆成多个小 Hash；将大 List 拆分成多个子 List。
    • 压缩：对于长文本，可在客户端压缩/解压（牺牲 CPU）。
    • 选择合适数据类型：例如，仅需判断成员是否存在时，使用 Set 而非 List。
• 选择合适的数据类型
  • 存储对象：优先使用 Hash，而非将整个对象序列化为 JSON String。Hash 支持字段级读写，更节省网络和内存。
  • 需要排序和分页：使用 ZSet（有序集合）。
  • 需要快速判断是否存在、去重：使用 Set。
  • 模拟队列/栈：使用 List。对于复杂消息场景，Redis 5.0+ 推荐使用 Stream。
  • 需要精确去重计数：使用 HyperLogLog（有微小误差，但极其节省空间）。

3. 生命周期管理（TTL）

• 所有缓存数据必须设置过期时间（TTL），防止数据永驻内存，导致内存泄漏。
• 设置原则：
  • 固定过期：适用于数据冷热均匀的场景。
  • 随机过期：在批量加载缓存时，在基础过期时间上增加一个随机值，防止大量缓存同时失效，引发缓存雪崩。
  • 滑动过期：通过 TTL 命令查询并重新设置过期时间，适用于活跃数据。
• 区分数据类别：
  • 缓存类数据：必须设置 TTL。
  • 持久类数据（如计数器、配置项）：可以不设 TTL，但必须严格监控其增长，并纳入内存预算。

---

二、命令使用与操作规范

1. 命令禁忌

• 线上禁用命令：KEYS, FLUSHALL, FLUSHDB, CONFIG。这些命令会阻塞 Redis 或带来巨大安全风险。
• 替代方案：
  • 使用 SCAN 命令及其变体（HSCAN, SSCAN, ZSCAN）替代 KEYS 和 HGETALL 等，它们是游标式的，不会阻塞。
  • 通过 Redis 配置文件重命名或彻底禁用危险命令：rename-command KEYS ""。

2. 高效使用命令

• 使用批量操作：
  • 对于多个无依赖的写或读操作，使用 MSET/MGET（注意大 Key 问题）或 Pipeline（管道），将多个命令打包一次发送，极大减少网络往返时间（RTT）。
• 使用原子操作：
  • 对于需要多个步骤且需要原子性完成的逻辑，使用 Lua 脚本。脚本在服务端原子执行，效率高且无竞态条件。
• 避免低效操作：
  • 避免在循环中频繁调用 Redis 命令。
  • 使用 EXISTS 判断 Key 是否存在后，再执行后续操作，存在竞态条件。应直接使用 SET key value NX 这类原子命令。

---

三、数据持久化与安全

• 理解持久化策略：
  • RDB：定时快照，恢复快，但可能丢失最后一次快照后的数据。
  • AOF：记录所有写命令，数据完整性高，但文件更大，恢复更慢。
  • 混合持久化（Redis 4.0+）：推荐使用，结合两者优点。AOF 文件包含了 RDB 头和增量 AOF 日志。
• 备份与恢复：
  • 必须有定期的数据备份策略和恢复演练流程。
• 安全：
  • 生产环境必须设置密码（requirepass）。
  • 绑定必要端口，通过防火墙限制客户端源 IP 访问。
  • 使用非默认端口。

---

四、高可用与集群规范

• 生产环境禁用单机模式。
• 架构选择：
  • 主从复制（Replication）：提供数据备份和读扩展，但主节点故障需手动切换。
  • 哨兵模式（Sentinel）：提供主从故障的自动切换，实现高可用。至少需要 3 个哨兵实例。
  • 集群模式（Cluster）：提供数据分片（Sharding）和高可用，是应对海量数据和超高并发的标准方案。
• 集群模式下的特殊规范：
  • 避免大 Key：单个大 Key 会导致某个分片内存压力过大，影响集群平衡和性能。
  • 使用 Hash Tag：对于需要跨 Key 批量操作（如 MGET）或事务的场景，可以使用 {} 将 Key 的一部分括起来，确保相关的多个 Key 被路由到同一个哈希槽。例如：{user:1001}:profile 和 {user:1001}:orders。
  • 客户端要求：必须使用支持集群协议的客户端（如 Lettuce, JedisCluster），并能正确处理 MOVED/ASK 重定向。

---

五、运维与监控规范

• 内存规划：
  • 必须配置 maxmemory 参数，并设置合理的 maxmemory-policy（如 allkeys-lru 或 volatile-lru）。
• 监控指标：
  • 资源：内存使用率、CPU 使用率、连接数。
  • 性能：QPS、每秒命令数、请求延迟（P50, P99, P999）、慢查询数量。
  • 持久化：最后一次 RDB/AOF 成功时间。
• 慢查询监控：
  • 配置 slowlog-log-slower-than 参数（如 10 毫秒），并定期分析慢查询日志 slowlog get。
• 告警：
  • 对内存使用率、连接数、延迟、主从中断等关键指标设置告警阈值。

---

六、通用最佳实践总结

1. 缓存不是存储：始终要有缓存失效后的降级方案（如回源数据库）。
2. 保证数据最终一致性，而非强一致性。缓存数据与源数据存在延迟是正常现象。
3. 先写数据库，再删缓存（Cache-Aside 模式），而非先删缓存再写库，以降低竞态条件风险。
4. 容量预估：上线前必须对数据量、QPS、平均 Value 大小进行预估，进行容量规划。
5. 变更管理：任何对 Redis 配置、版本、架构的变更，都需在测试环境充分验证，并有回滚方案。

遵循以上规范，可以构建一个高性能、高可用、可维护且稳定的 Redis 应用体系。当然，这里还有一些更深层次和补充的 Redis 开发规范，这些规范往往源于实际生产环境中的经验教训。

---

七、高级设计与模式规范

1. 缓存模式规范

• Cache-Aside (Lazy Loading)
  • 读流程：先读缓存，命中则返回；未命中则读数据库，写入缓存后返回。
  • 写流程：先更新数据库，再删除缓存。这是最经典的缓存更新策略。
  • 关键点：
    • 删除缓存而非更新缓存，避免并发写操作导致缓存脏数据。
    • 可能存在"更新数据库后，删除缓存前"的短暂数据不一致，但概率低，通常可接受。
• Write-Through/Write-Behind
  • 由缓存层自己负责同步写数据库，对应用透明。此模式通常需要专门的缓存组件支持，Redis 原生不支持，需在客户端封装，复杂度高，慎用。
• 缓存预热
  • 在系统上线、重启或大规模活动前，通过批处理任务将热点数据提前加载到 Redis 中，避免瞬时流量压垮数据库。
• 多级缓存
  • 对于极端热点数据，可采用 应用本地缓存（如 Caffeine） + Redis 的两级缓存架构。
  • 规范：本地缓存 TTL 应更短，并在数据更新时要有机制（如消息广播）来失效所有应用节点的本地缓存。

2. 分布式锁规范

• 首选 Redlock 算法
  • 在需要强一致性的分布式锁场景，应使用官方推荐的 Redlock 算法，在多个独立的 Redis 实例上同时申请锁。
  • 单 Redis 节点的锁仅用于业务协-调，不用于资金安全等对一致性要求极高的场景。
• 设置随机值作为锁标识
  • 锁的 Value 必须是一个全局唯一的随机字符串（如 UUID），用于标识加锁的客户端。解锁时需用 Lua 脚本验证 Value 再删除，防止误删其他客户端的锁。
• 设置合理的超时时间
  • 锁必须设置一个合理的过期时间（TTL），防止客户端崩溃导致锁永远无法释放。
  • 锁的持有时间应远小于业务操作的最大预估时间。

3. 延迟与管道优化

• 警惕序列化成本
  • 复杂的序列化方式（如 JDK 原生、JSON）在 Value 很大时，CPU 开销不容忽视。在高压下可能成为瓶颈。
• 监控网络往返次数（RTT）
  • 性能优化核心之一是减少应用与 Redis 服务器的网络通信次数。Pipeline 和 Lua 脚本是解决此问题的关键工具。

---

八、稳定性与风险控制规范

1. 容量与性能规划

• 内存容量规划
  • 预留 20%-30% 的内存余量，以应对流量突增和内存碎片。
  • 监控 mem_fragmentation_ratio（内存碎片率），过高（如 > 1.5）可能需要重启整理。
• 连接数管理
  • 合理配置客户端连接池参数，避免创建过多连接压垮服务器。
  • 监控 connected_clients，并设置 maxclients 限制。
• 热点 Key 识别与处理
  • 定义：某个 Key 的 QPS 远高于其他 Key。
  • 危害：可能导致单个 Redis 节点 CPU 负载过高。
  • 解决方案：
    • 本地缓存：将该热点数据缓存在应用本地。
    • 拆分：将热点 Key 拆分成多个子 Key，分散到不同节点（如 hotkey:1, hotkey:2），在客户端进行随机或哈希访问。

2. 慢查询与阻塞规避

• **监控 **slowlog
  • 定期分析慢查询日志，找出并优化执行时间过长的命令。
• 规避阻塞性操作
  • 除了 KEYS、FLUSHALL，还需注意：
    • 执行 SAVE 命令（推荐 BGSAVE）。
    • 删除超大 Key（使用 UNLINK 替代 DEL，它是异步的）。
    • 在集合元素数量巨大时，使用 HGETALL, SMEMBERS, LRANGE 0 -1（应使用 HSCAN, SSCAN, LRANGE 分页）。

3. 客户端规范

• 资源释放
  • 确保在使用完 Redis 连接后，将其正确返还给连接池。避免连接泄漏。
• 异常处理
  • 代码必须有健全的异常处理逻辑。当 Redis 操作失败时，应有降级策略（如直接查询数据库、返回默认值等），保证核心业务流程不中断。
• 重试策略
  • 对于网络抖动等临时性故障，客户端应具备有退避策略的重试机制（如指数退避），避免雪崩。

---

九、业务逻辑与数据一致性规范

• 明确缓存边界
  • 在架构设计文档中明确写明：哪些数据被缓存、缓存的 Key 规则、TTL 策略、更新策略（Cache-Aside 等）。这有助于团队协作和问题排查。
• 容忍数据延迟
  • 从架构层面接受缓存与源数据之间的短暂不一致。如果业务不能接受，则应考虑不适用缓存，或使用其他强一致性方案。
• 避免将 Redis 用于复杂事务
  • Redis 的事务（MULTI/EXEC）并非 ACID 事务，它只是确保命令被顺序、原子地执行，不具备回滚能力。复杂业务逻辑应放在数据库中。

---

十、流程与协作规范

• 变更管理
  • 任何对 Redis 配置、版本、数据结构的变更，都必须经过严格的测试环境验证，并有清晰、可执行的回滚方案。
• 文档化
  • 维护一个内部的 Redis 使用文档，记录所有自定义的 Key 命名规范、数据类型、TTL 策略、负责团队等信息。这对于新成员上手和故障排查至关重要。

---

十一、 数据清理与生命周期管理规范

1. 渐进式清理

• **避免 **FLUSHDB/FLUSHALL：即使在维护窗口，也严禁在生产环境使用，可能导致 Redis 阻塞或内存瞬间释放引发操作系统 OOM Killer。
• 推荐使用 SCAN + DEL/UNLINK：对于需要清理大量符合模式的 Key，必须编写脚本，使用 SCAN 命令遍历，并结合 DEL（对于小Key）或 UNLINK（对于任何Key，异步非阻塞）逐个删除。
• 设置过期时间而不是主动删除：对于生命周期结束的数据，优先设置一个较短的 TTL 让其自动过期，而非立即删除，这可以将删除操作的压力分摊到时间线上。

2. 过期策略与内存回收

• 理解 volatile-* 策略：使用 volatile-lru 等策略时，必须确保所有缓存数据都设置了 TTL，否则无 TTL 的数据会成为“永久数据”，永远不被回收。
• 监控过期 Key 的删除速率：使用 info stats 命令查看 expired_keys 和 evicted_keys 的变化趋势。如果 evicted_keys 持续快速增长，说明内存已满并开始强制淘汰，需要紧急扩容或优化数据。

---

十二、 客户端架构与配置规范

1. 连接池精细化配置

• 连接池大小不是越大越好：过大的连接池会导致 Redis 服务器忙于线程上下文切换，反而降低性能。一个参考公式是 连接数 ≈ (QPS / 1000) * 平均响应时间(ms)，并从一个小数值开始压力测试调整。
• 配置空闲连接检测：开启 testWhileIdle、timeBetweenEvictionRuns 等参数，让连接池能自动剔除失效的连接，并创建新的健康连接。

2. 读写分离与路由

• 只读场景使用从节点：对于可以接受短暂延迟的读请求，可以在客户端配置，将其路由到 Redis 从节点（Replica），减轻主节点压力。
• 明确读写路径：在架构图中明确标出哪些操作走主节点，哪些可以走从节点，避免在代码中随意指定连接，造成数据不一致或主节点压力过大。

---

十三、 安全与权限管控规范

1. 最小权限原则

• 使用不同权限的账户：如果 Redis 6.0+ 的 ACL 功能可用，应为不同业务应用创建专属账户，并授予其最小必要权限。例如，一个只做缓存的应用，只应拥有 GET、SET、DEL 等命令的权限，禁用 CONFIG、FLUSH* 等危险命令。
• 网络层面隔离：将 Redis 部署在独立的私有网络段，通过安全组/防火墙规则严格限制访问源 IP，仅允许特定的应用服务器访问。

2. 敏感信息处理

• 禁止存储明文敏感信息：严禁将用户密码、身份证号、手机号等明文敏感信息存入 Redis。如需存储，应进行不可逆脱敏（如哈希）或强加密。
• 日志脱敏：确保应用的日志配置不会将完整的 Redis Key 或 Value（特别是包含用户ID等信息的）打印到日志文件中，防止敏感信息泄露。

---

十四、 监控、告警与可观测性规范

1. 超越基础指标

• 监控 Key 空间：定期采样分析 Key 的前缀分布，及时发现异常增长的业务 Key 或遗忘的无TTL Key。
• 监控复制状态：在主从/集群模式下，持续监控 master_link_status、master_last_io_seconds_ago 等指标，确保主从同步健康。
• 监控持久化状态：监控 rdb_last_bgsave_status 和 aof_last_write_status，确保备份机制正常。监控 aof_current_size 和 aof_base_size，警惕 AOF 文件过大。

2. 建立完整的可观测性

• 在客户端埋点：除了监控 Redis 服务器，还应在应用端监控每次 Redis 操作的耗时、失败率，这样才能从用户视角真正发现问题。
• 建立端到端追踪：在分布式链路追踪系统（如 SkyWalking, Jaeger）中，将 Redis 命令执行作为一个 Span，便于在复杂调用链中定位性能瓶颈。

---

十五、 成本优化规范

1. 内存优化

• 使用 ziplist 等编码优化：了解并合理配置 hash-max-ziplist-entries、zset-max-ziplist-entries 等参数，让小集合使用更紧凑的编码方式存储，节省内存。但需注意，调整这些参数可能增加 CPU 开销。
• 升级 Redis 版本：新版本 Redis（如 7.0）通常在内存效率和性能上有所提升，例如更好的数据结构。在评估兼容性后，应考虑升级。

2. 实例规划

• 拆分多实例：对于大型应用，可以根据业务域（如用户、订单、商品）拆分成多个独立的 Redis 实例。这有助于隔离故障、精细化监控和成本核算（例如，不同实例可选择不同规格）。
• 选择合适规格：在云服务上，选择与业务负载匹配的实例规格。对于容量需求大但 QPS 不高的场景，可选择大内存规格；对于高 QPS 场景，可选择高性能规格。

---

十六、 混沌工程与韧性规范

• 定期进行故障演练：在测试环境，模拟 Redis 节点宕机、网络分区、主从切换等故障，验证客户端的容错能力、重连机制和业务的降级策略是否如预期工作。
• 制定清晰的应急预案：文档化地记录当发生 Redis 完全不可用、数据错误、容量爆满等极端情况时，运维和开发人员的具体操作步骤，包括如何切换流量、如何降级、如何恢复数据。

---

十七、 数据结构深度使用规范

1. 流数据结构的正确使用

• 消息保序与消费：使用 XADD 添加消息，使用 XREADGROUP 进行消费组的消费。确保每个消息都有唯一的序列号。
• Pending List 监控：必须监控 XPENDING，关注未被确认（ACK）的消息数量。持续增长的 Pending List 通常意味着消费者出现故障或性能瓶颈。
• 避免 Stream 无限增长：使用 XADD 时指定 MAXLEN 参数（例如 XADD mystream MAXLEN ~ 1000 * ...），使用 ~ 进行近似修剪以保证性能，防止 Stream 成为大 Key。

2. 概率性数据结构的适用场景

• HyperLogLog 用于基数统计：适用于大规模数据的近似去重计数，如 UV 统计。优点是极其节省内存，但有小概率误差（标准误差约 0.81%），且无法获取元素本身。
• Bloom Filter 用于存在性判断：适用于判断某个元素是否一定不存在或可能存在，如推荐去重、防止缓存穿透。Redis 4.0 后可通过 BF.RESERVE、BF.ADD、BF.EXISTS 使用。能有效节省内存，但有误判率。

---

十八、 集群与扩展性深度规范

1. 集群运维规范

• 集群节点数量：生产环境 Redis Cluster 至少需要 6 个节点（3主3从）。主节点负责数据分片和读写，从节点负责高可用和读扩展。
• 安全的重配置操作：进行集群节点扩容、缩容时，必须使用 redis-cli --cluster reshard 等工具，并确保数据迁移在业务低峰期进行。缩容前必须确保节点数据已清空。
• 集群状态监控：除了基础监控，还需监控集群的 cluster_state（是否为 ok）以及所有节点的 cluster_stats_messages_sent 和 cluster_stats_messages_received，异常的消息量可能预示网络分区或节点故障。

2. 跨数据中心规范

• 主动-被动模式：通常采用主从复制，将主集群部署在一个数据中心（Active），从集群部署在另一个数据中心（Passive）用于灾备。
• 禁止跨数据中心直连：应用程序严禁直接跨数据中心网络访问 Redis。延迟和网络不稳定性将导致灾难性后果。应通过就近访问代理或服务网格来路由请求。
• 同步延迟容忍：必须明确业务是否能接受跨数据中心复制带来的数据延迟。在容灾切换时，可能会丢失最后一次未同步的数据。

---

十九、 客户端高级行为规范

1. 防止缓存污染

• 缓存非正常结果：对于数据库查询为 NULL 或抛异常的情况，也应进行缓存（缓存一个空对象或特殊标记），并设置一个较短的 TTL（如 30-60 秒）。这被称为 “缓存空对象” 策略，是防止缓存穿透（大量请求不命中直达数据库）的核心手段。
• 缓存降级结果：当源服务不可用时，可以将旧的、略有过时的数据作为降级结果继续提供服务，并在缓存中标记为降级数据，同时设置告警。

2. 热点发现与自动治理

• 在客户端实现热点探测：在应用层通过简单的计数统计，发现短时间内访问频率极高的 Key。
• 实现本地缓存“兜底”：一旦被识别为热点 Key，自动将其加载到应用本地缓存（如 Guava Cache, Caffeine）中，并设置一个很短的 TTL（如 2 秒）。这样，在接下来的短时间内，请求不会打到 Redis，直到本地缓存过期。这实现了热点的自动拆分和卸载。

---

二十、 数据备份与恢复规范

1. 备份策略

• 混合持久化备份：确保开启 aof-use-rdb-preamble yes，这样 AOF 文件更紧凑，恢复更快。定时对 AOF 文件进行归档备份。
• 物理备份与逻辑备份结合：
  • 物理备份：直接备份 RDB 文件和 AOF 文件。恢复快，适合大规模数据。
  • 逻辑备份：使用 redis-cli --rdb 或 redis-cli --bigkeys 等工具进行特定数据的导出和检查。灵活性高，适合小规模数据迁移或检查。

2. 恢复演练

• 定期恢复演练：备份的价值在于能够成功恢复。必须定期（如每季度）在隔离的环境中，使用备份文件进行完整的数据库恢复演练，并验证数据的完整性和一致性。记录恢复所需时间（RTO）。

---

二十一、 文档与文化规范

• 维护数据字典：建立一个中央化的文档（如 Confluence/Wiki），记录所有核心的 Redis Key 的格式、数据类型、业务含义、TTL 策略、负责团队和联系人。这是故障排查和新成员上手的宝贵资源。
• 建立“Redis 守护者”角色：在团队中指定或轮值一名“Redis 守护者”，负责在本周期内监控 Redis 健康状况、处理告警、review 新的 Redis 使用代码、维护数据字典，从而将规范落到实处。

这些深度规范将 Redis 的使用从“能用”提升到了“好用”和“敢用”的级别，特别是在大规模、高要求的生产环境中，它们是系统长期稳定运行的基石。