阿里云 Redis 开发规范是一套针对使用阿里云 Redis 数据库的最佳实践指南，涵盖键值设计、命令使用、客户端配置及架构选型等方面。通过遵循该规范，团队可以统一编码风格，避免 BigKey 引发的性能瓶颈，减少数据不一致风险。规范中明确的关键命名规则、过期时间策略及禁用命令列表，能显著降低运维成本，提升代码可维护性，从而增强团队协作效率并确保系统稳定高效运行。
Redis 开发规范
Redis 开发规范 总体规约以《阿里云 Redis 开发规范》为主，请开发人员至少阅读一遍该手册。总体要求 Redis 主要用于缓存处理，加快读取效率，但在使用过程中需要注意合理的使用，一般存储全局配置数据和一些访问非常频繁的较为静态的数据，另外注意过期时间控制，减少资源的不必要消耗。模块级固定段：服务简码：模块简码：例:hpfm:fnd: 服务级固定段：服务简码：例:hpfm: key 名设计 可读性和可管理性 以业务名 (或数据库名) 为前缀 (防止 key 冲突),用冒号分隔，比如平台服务：基础模块：配置文件 (Hash 结构的 key) hpfm:fnd:profile 简洁性 保证语义的前提下，控制 key 的长度，当 key 较多时，内存占用也不容忽视，例如：user:{uid}:friends:messages:{mid} 简化为 u:{uid}:fr:m:{mid} 不要包含特殊字符 反例：包含空格、换行、单双引号以及其他转义字符 value 设计 拒绝 bigkey(防止网卡流量、慢查询) string 类型控制在 10KB 以内，hash、list、set、zset 元素个数不要超过 5000。反例：一个包含 200 万个元素的 list。非字符串的 bigkey，不要使用 del 删除，使用 hscan、sscan、zscan 方式渐进式删除，同时要注意防止 bigkey 过期时间自动删除问题 (例如一个 200 万的 zset 设置 1 小时过期，会触发 del 操作，造成阻塞，而且该操作不会不出现在慢查询中 (latency 可查)),查找方法和删除方法 选择适合的数据类 例如：实体类型 (要合理控制和使用数据结构内存编码优化配置，例如 ziplist，但也要注意节省内存和性能之间的平衡) 反例：set user:1:name tom set user:1:age 19 set user:1:favor football 控制 key 的生命周期 建议使用 expire 设置过期时间 (条件允许可以打散过期时间，防止集中过期),不过期的数据重点关注 idletime。Redis 操作 建议使用 Spring 提供的 RedisTemplate 对象进行操作，项目中进行一定的封装，是操作和使用保持一致的风格，便于后续的维护。先操作缓存，还是先操作数据库 希望保证操作缓存和操作数据库的原子性，要么同时成功，要么同时失败。这演变为一个分布式事务的问题，保证原子性十分困难，很有可能出现一半成功，一半失败。1.先操作数据库，再操作缓存 正常情况下：(1) 先操作数据库，成功；(2) 再操作缓存 (delete 或者 set),也成功 如果第一步就失败，可以返回调用方 50X，不会出现数据不一致。但如果这两个动作原子性被破坏：第一步成功，第二步失败，会导致，数据库里是新数据，而缓存里是旧数据，业务无法接受。2.先操作缓存，再操作数据库；正常情况下：(1) 先操作缓存 (delete 或者 set),成功;（2026 年 4 月 9 日）
一份完整的阿里云 Redis 开发规范
一份完整的阿里云 Redis 开发规范 阿里云 Redis(ApsaraDB for Redis) 是一款兼容开源 Redis 协议的高性能 Key-Value 数据库，提供缓存、持久化、弹性扩缩容、备份恢复、容灾等多种能力。随着业务的发展，Redis 的使用场景越来越广泛，但若缺乏规范指导，容易引发性能瓶颈、数据不一致、安全漏洞等问题。本文旨在总结阿里云 Redis 的最佳实践经验，形成一套完整的开发规范，帮助开发者高效、安全、稳定地使用 Redis。2. Redis 基础规范 2.1 选择合适的实例规格 阿里云 Redis 提供多种系列和规格：社区版、企业版 (性能增强型、混合存储型等),以及内存型、持久内存型等。开发前需根据业务预估 QPS、数据量、并发连接数、持久化要求等选择合适规格。建议：QPS 预估：预留 30%~50% 的冗余，避免流量突增导致限流。内存容量：考虑数据有效期、淘汰策略、碎片率，建议实际使用内存不超过规格的 80%。网络带宽：关注实例的网络吞吐能力，尤其在使用大 Value 或批量操作时。连接数限制：不同规格有最大连接数限制，需合理配置客户端连接池。2.2 部署架构选型 标准版：单副本或双副本 (主备),适用于缓存场景或对可用性要求不高的业务。集群版：数据分片，支持更大数据量和更高并发，适用于海量数据存储和超高 QPS 场景。读写分离版：主节点负责写，从节点负责读，适用于读多写少场景，需注意数据同步延迟。企业版 (Tair):提供增强型数据结构 (如 TairString、TairHash、TairGIS 等) 和高级功能 (如 BloomFilter、TairCpc 等),可根据业务需求选用。（该信息的时间戳是 2026 年 2 月 27 日）
一份完整的阿里云 Redis 开发规范，值得收藏!
一份完整的阿里云 Redis 开发规范，值得收藏! 简介：本文介绍了在使用阿里云 Redis 的开发规范，从键值设计、命令使用、客户端使用、相关工具等方面进行说明，通过本文的介绍可以减少使用 Redis 过程带来的问题。一、键值设计 1. key 名设计 (1)【建议】: 可读性和可管理性 以业务名 (或数据库名) 为前缀 (防止 key 冲突),用冒号分隔，比如业务名：表名:id ugc:video:1 一键获取完整项目代码 go (2)【建议】:简洁性 保证语义的前提下，控制 key 的长度，当 key 较多时，内存占用也不容忽视，例如：user:{uid}:friends:messages:{mid} 简化为 u:{uid}:fr:m:{mid}。一键获取完整项目代码 go (3)【强制】:不要包含特殊字符 反例：包含空格、换行、单双引号以及其他转义字符 详细解析 2. value 设计 (1)【强制】:拒绝 bigkey(防止网卡流量、慢查询) string 类型控制在 10KB 以内，hash、list、set、zset 元素个数不要超过 5000。反例：一个包含 200 万个元素的 list。非字符串的 bigkey，不要使用 del 删除，使用 hscan、sscan、zscan 方式渐进式删除，同时要注意防止 bigkey 过期时间自动删除问题 (例如一个 200 万的 zset 设置 1 小时过期，会触发 del 操作，造成阻塞，而且该操作不会不出现在慢查询中 (latency 可查)),查找方法和删除方法 详细解析 (2)【推荐】:选择适合的数据类型。例如：实体类型 (要合理控制和使用数据结构内存编码优化配置，例如 ziplist，但也要注意节省内存和性能之间的平衡) 反例：set user:1:name tom set user:1:age19 set user:1:favor football 一键获取完整项目代码 go 正例：hmset user:1name tom age19favor football 一键获取完整项目代码 go 3.【推荐】:控制 key 的生命周期，redis 不是垃圾桶。建议使用 expire 设置过期时间 (条件允许可以打散过期时间，防止集中过期),不过期的数据重点关注 idletime。二、命令使用 1.【推荐】O(N) 命令关注 N 的数量 例如 hgetall、lrange、smembers、zrange、sinter 等并非不能使用，但是需要明确 N 的值。有遍历的需求可以使用 hscan、sscan、zscan 代替。2.【推荐】:禁用命令 禁止线上使用 keys、flushall、flushdb 等，通过 redis 的 rename 机制禁掉命令，或者使用 scan 的方式渐进式处理。3.【推荐】合理使用 select redis 的多数据库较弱，使用数字进行区分，很多客户端支持较差，同时多业务用多数据库实际还是单线程处理，会有干扰。4.【推荐】使用批量操作提高效率 原生命令：例如 mget、mset。非原生命令：可以使用 pipeline 提高效率。（截至 2022 年 9 月 9 日）
FAQ
为什么要拒绝 bigkey？
防止网卡流量、慢查询。string 类型控制在 10KB 以内，hash、list、set、zset 元素个数不要超过 5000。
线上禁止使用哪些命令？
禁止线上使用 keys、flushall、flushdb 等，通过 redis 的 rename 机制禁掉命令，或者使用 scan 的方式渐进式处理。
如何控制 key 的生命周期？
建议使用 expire 设置过期时间 (条件允许可以打散过期时间，防止集中过期),不过期的数据重点关注 idletime。