Redis 运维规范_key 设计规范
一、key 设计规范
1、设计合理的Key名称与长度
Key名称：要见名知其意，方便快速定位问题及相关业务。key 名称要避免使用单双引号、转义字符等特殊符号。
key长度：在能完整描述业务的前提下尽量精简，推荐Key名的长度不超过128字节（越短越好）
2、合理使用类型
Redis提供了丰富的数据类型，可以根据业务场景选择合适的类型。一般情况下可以选择命令复杂度较低的 string 类型，但是对于小数据存储来说元数据内存开销较大，内存利用率会较低。对于使用压缩列表结构的 hash 类型来说，可以很好的提升内存利用率，但命令复杂度会较高。
除 string 外，其余数据类型均含有两种底层数据结构，需合理的设置使用才可以达到想要的效果。
3、大 key
合理设置 key 的 value 大小，避免出现大 key。大 key 容易造成集群数据倾斜；在对大 key 进行遍历操作时，可能会造成流量、CPU 等资源打高，时延变长，影响 Redis 性能。
建议：
(1) 对大 key 进行拆分
(2) 在对大 key 删除时：对于 Redis 4.0及之后版本，建议使用 UNLINK 命令异步删除；对于 Redis 4.0 之前的版本，建议使用 scan 命令分批读取数据，然后再进行删除，避免一次性删除大 key 导致 redis 阻塞。
4、热 key
热 key 会导致集群架构下某个数据分片被大量访问、单个数据分片的压力无法下降，而其他数据分片处于空闲状态的情况。严重的话，热Key的请求压力数量超出Redis的承受能力易造成缓存击穿。
建议：
(1) 热 key 可以考虑读写分离架构分担读压力
(2) 对于热 key 要注意过期时间，避免出现热 key 过期导致大量相关查询直接访问至后段数据库的情况
5、合理使用 hash tag
hash tag 主要作用是将某一固定特征数据存储到一台实例上，合理利用可以避免逐个查询集群中实例。但该操作可能会导致数据集中在一个实例中，造成集群内存倾斜。
6、合理设置 key 过期时间
key 过期时间设置主要需要关注两点：
(1) 避免永久不过期设计:非必要建议使用 expire 给所有 key 设置过期时间，防止 Redis 中残留大量的废弃数据。
(2)避免同一时间大量 key 同时过期。缓存中有大量数据同时过期，导致大量请求无法得到处理，容易出现缓存雪崩。建议缓存的过期时间加上一个随机值时间，将过期时间打散。
