本节主要介绍Redis常见使用规范，包括业务使用规范、SDK使用规范等
业务使用规范
规范 | 规范说明 | 级别 | 备注 |
业务数据分离 | 防止由于Redis故障或不可用影响所有相关业务收到干扰 | 建议 | 业务数据分离，避免多个应用使用一个Redis实例，不相干的业务拆分，公共数据做服务化 |
完善redis的容错处理 | 缓存可能会遇到基础设施的故障或主备切换，应用需要对可能的故障和慢请求做容错处理。 | 建议 | 缓存访问失败时，具备降级措施，从DB获取数据；或者具备容灾措施，自动切换到另一个Redis使用； |
避免redis内存使用量超过80% | 避云主机会有一定的内存冗余，但是redis内存过高时，redis全量持久化时引入的COPY-ON-WRITE机制带来额外的内存消耗，再加上大内存带来的内存碎片和云主机相关的管理进程消耗，容易触发操作系统OOM KILL | 强制 | 建议及时做扩容处理 |
防止缓存击穿 | 防止缓存击穿，推荐搭配本地缓存使用Redis，对于热点数据建立本地缓存。本地缓存数据使用异步方式进行刷新 | 建议 | - |
就近部署业务 | 避免网络延迟将极大影响读写性能，如果对于时延较为敏感，请避免使用跨AZ Redis实例 | 建议 | - |
不当成消息队列 | 发布订阅场景下，不建议作为消息队列使用。redis的PUB/SUB支持的性能有限。 | 强制 | 如果需要消息队列，建议改用kafka或rabbitmq |
Key名称的使用规范
规范 | 规范说明 | 级别 | 备注 |
使用统一的命名规范 | 一般使用业务名(或数据库名)为前缀，用冒号分隔 | 建议 | 例如，业务名:表名:id |
控制key名称的长度 | 在保证语义清晰的情况下，Key的长度越短越好。有些常用单词可使用缩写 | 建议 | 例如，user缩写为u，messages缩写为msg。建议长度不超过128字节。 |
名称中不要包含特殊字符 | 禁止包含特殊字符，如空格、换行、单双引号、中文或其他转义字符 | 强制 | 大括号（{}）为Redis的hash tag语义,如果使用cluster集群实例， KEY名称需要正确使用，避免引发数据倾斜，数据都分在同一个SLOT上。 |
Value值的使用规范
规范 | 规范说明 | 级别 | 备注 |
要避免大Key、热Key | 大Key会带来网卡流量风暴和慢查询，要避免出现大Key和热KEY | 强制 | 一般string类型控制在10KB以内，hash、list、set、zset元素个数不要超过1000 |
选择合适的数据类 | 选择合适的数据类型能够节省内存、带宽和提升性能。 | 建议 | 比如存储用户的信息，可用使用多个key，使用set u:1:name "X"、set u:1:age 20这样存储，也可以使用hash数据结构，存储成1个key，设置用户属性时使用hmset一次设置多个，同时这样存储也能节省内存 |
设置合理的过期时间 | 最好是过期时间打散，不要集中在某个时间点过期。 | 建议 | 避免Redis因为处理大量过期KEY导致CPU使用率飙高导致性能不稳定。 |
Redis命令的常用规范
规范 | 规范说明 | 级别 | 备注 |
小心使用时间复杂度为O(N)的命令 | 对于时间复杂度为O(N)的命令如果N值较大，可能会导致Redis执行过慢，影响整体性能和稳定性 | 强制 | 例如：hgetall、lrange、smembers、zrange、sinter这些命令都是做全集操作，如果元素很多，是很耗性能的可使用hscan、sscan、zscan这些分批扫描的命令替代 |
命令禁用 | 部分命令是禁止使用的，需要最好提早了解清楚 | 强制 | 使用前，请参考Redis命令兼容性和WebCli命令兼容性 |
慎重使用select | Redis多数据库支持较弱，多业务用多数据库实际还是单线程处理，会有干扰 | 建议 | 需要多DB的场合，建议拆分多个redis使用 CLUSTER集群实例不支持多DB |
批量操作 | 如果有批量操作，可使用mget、mset或pipeline，提高效率，但要注意控制一次批量操作的元素个数免得导致执行过慢，占用Redis过多的资源 | 建议 | l 如果有批量操作，可使用mget、mset或pipeline，提高效率，但要注意控制一次批量操作的元素个数mget、mset和pipeline的区别如下：mget和mset是原子操作，pipeline是非原子操作 l pipeline可以打包不同的命令，mget和mset做不到 l 使用pipeline，需要客户端和服务端同时支持 |
lua脚本执行耗时 | lua脚本的执行超时时间为5秒钟，建议不要在lua脚本中使用比较耗时的代码 | 强制 | 比如长时间的sleep、大的循环等语句 |
避免在lua脚本中使用随机函数 | 调用lua脚本时，建议不要使用随机函数去指定key，否则在主备节点上执行结果不一致，从而导致主备节点数据不一致 | 强制 | - |
遵循CLUSTER集群实例使用lua的限制 | 遵循CLUSTER集群实例使用lua的限制 | 强制 | l cluster集群实例使用lua有如下限制：使用EVAL和EVALSHA命令时，命令参数中必须带有至少1个key，否则客户端会提示“ERR eval/evalsha numkeys must be bigger than zero in redis cluster mode”的错误 l 使用EVAL和EVALSHA命令时，cluster集群实例使用第一个key来计算slot，用户代码需要保证操作的key是在同一个slot |
不要直接使用del命令删除大Key | 删除大Key时，不要直接使用del命令因为del命令是阻塞的，也会同时阻塞其他客户端请求无法正常执行 | 强制 | Redis 4.0后的版本可以通过UNLINK命令安全地删除大Key，该命令是异步非阻塞的 |
l 对于 4.0之前的版本：如果是Hash类型的大Key，推荐使用hscan + hdel l 如果是List类型的大Key，推荐使用ltrim l 如果是Set类型的大Key，推荐使用sscan + srem l 如果是SortedSet类型的大Key，推荐使用zscan + zrem | |||
控制pipeline命令个数 | 使用Pipeline时，建议不要一次太多命令因为会占用大量Redis资源和执行时间较长，可能会卡住其他请求无法执行 | 建议 | 单次建议不超过100，同时也需要考虑实际元素字节数大小情况 |
合理使用发布订阅命令 | 不建议将 Redis 当作消息队列使用Redis 当作消息队列使用，会有容量、网络、效率、功能方面的多种问题 | 建议 | 如需要消息队列，可使用高吞吐的Kafka或者高可靠的RabbitMQ |
Redis事务限制 | Redis事务是不支持回滚的如果事务在中途某个命令失败了，那么前面的命令依然会执行成功 | 建议 | - |
SDK使用规范
规范 | 规范说明 | 等级 | 备注 |
使用连接池+长连接 | 短连接性能差，建议使用连接池+长连接，可以有效控制连接，同时提高效率 | 建议 | 推荐使用JedisPool或者JedisCluster连接实例。 |
避免使用Lettuce客户端 | Jedis客户端在面对连接异常，网络抖动等场景下的异常处理和检测能力明显强于Lettuce，可靠性更强 | 建议 | 建议使用Jedis |
客户端需要对可能的故障和慢请求做容错处理 | 由于Redis服务可能因网络波动或基础设置故障的影响，引发主备切换、命令超时或慢请求等现象，需要在客户端内设计合理的容错重试机制 | 强制 | - |
合理设置重试时间和次数 | 根据业务要求合理设置容错处理的重试时间和次数，避免不合适的设置导致对服务的可用性收到影响 | 强制 | l 如果超时重试时间设置的非常短，可能引发重试风暴，极易引发业务层雪崩 l 如果重试时间设置得较长或者重试次数设置得较大，则可能导致在主备倒换情况下业务恢复较慢 |
运维管理规范
规范 | 规范说明 | 等级 | 备注 |
开启密码登录 | 生产环境需要开启Redis密码登录验证 | 强制 | - |
验证业务的故障处理能力或容灾逻辑 | 在测试环境或者预生产环境中组织演练，验证在Redis主备切换、宕机或者扩缩容场景下业务的可靠性 | 建议 | - |
监控实践 | 关注Redis负载，在过载前提前扩容 | 强制 | 根据告警基线配置告警：配置节点cpu、内存、带宽等告警 |
检查各个节点的内存使用率 | 例行检查各个节点的内存使用率，查看主节点内存使用率是否有不均衡的状态 | 建议 | 内存使用率不均衡说明存在大Key问题，需要进行大Key拆分及优化 |
开启热Key分析 | 开启热Key例行分析，并分析是否有Key频繁调用 | 建议 | - |
Redis慢日志 | 例行巡检Redis慢日志命令 | 建议 | 分析慢日志，并尽快从业务上进行修复 |