key命名风格

1需具有可读性以及可管理性，禁止毫无营养随意命名；

2 以英文字母开头，命名中只能出现小写字母、数字、英文点号 (.) 和英文半角冒号(:)；

3 不要包含特殊字符，如下划线、空格、换行、单双引号以及其他转义字符；

key命名规范

<应用名>:<业务模块名>:<业务逻辑含义>:<index>:<index>:...

1 以上的名称可以进行简写，但是要有明确的规划，团队能够达成共识。

 

2 单应用可以不用应用名。

 

3 建议key的命名的结尾加上value对应的类型或者类型结尾。提高可读性；

示例：api:emr:patient:{userid}:str

value存储规范

1 拒绝大key(防止网卡流量、慢查询)。

String 类型控制在 10KB 以内，Hash、List、Set、ZSet 元素个数不要超过 5000。

业务规范

1、优先不使用缓存，防止缓存服务屏蔽底层的性能低下的业务逻辑而不自知。导致缓存重建时业务卡顿。

2、redis 在缓存场景时候，应该是为核心的小数据为主，而且QPS比较高。同时缓存在失效或者丢失情况下，应该考虑缓存重建逻辑，不能影响正常业务。

3、对 key 设置合理的过期时间。

说明：

1）若不设置的过期时间，key会一直占用内存不释放，随着时间会达到服务器的内存上限，导致服务器宕机等重大事故；

 

2）对于需要长期有效，可以判断即将到期时，重新设置有效期，避免引起热点 key。

4、低频数据不建议放在redis中，避免浪费资源。

6、禁止大 key

再次重申，禁止将大 key 数据存⼊ Redis。

1）带来大的内存占用

 

2）读写大 key 会导致超时，网卡流量占满，甚至阻塞服务, 更甚者导致宕机。

 

3）删除大 key，DEL 命令可能阻塞 Redis 进程，对应用和 Redis 集群可用性造成严重的影响。

 

4）建议每个 key 不要超过 10Kb。

7、不可使用 Keys 之类的操作。类似操作生产环境一半会禁用掉。

8、选择合适的数据类型。

Redis 支持的数据库结构类型较多：字符串（String），哈希（Hash），列表（List），集合（Set），有序集合（Sorted Set）, Bitmap, HyperLogLog 和地理空间索引（geospatial）等, 需要根据业务场景选择合适的类型。这些之前的文章写过。

9、关于集合类操作

对于使用了 O(N) 的操作，导致服务超时，甚至服务不可用的问题。

1）使用 Set，Zset，List，Hash 等集合类的 O(N) 操作时，要预估 O(N) 操作的元素数量，避免全量操作，可以使用 HSCAN，SSCAN，ZSCAN 进行渐进操作。

 

2）集合元素数量过大在使用过程中会影响 Redis 的实际性能，Hash 类元素个数建议尽量不要超过 100，集合类、链表类数据尽量不要超过 10k。

 

3） 元素数量过大可考虑拆分成多个 key 进行处理。

10、合理的监控数据和服务性能，做好安全防护和性能提升的准备。

本文参考阿里云Redis开发规范