redis使用规范

本规范旨在帮助开发人员逐步建立合理使用数据库的意识，对数据库相关的资源申请、业务规范使用等提供规范性的指导，从而为公司业务系统稳定、健康地运行提供保障。

以下所有规范会按照【强制】、【建议】两个级别进行标注，对于【强制】级别的设计需强制修改调整。

[TOC]

基础规范

• 【强制】禁止在应用服务器上通过命令直连生产Redis服务
• 【强制】任何服务都不能保证100%可用，应用服务应当具备自动重连机制并不断提升自身的健壮性
• 【强制】Redis超时的设置，建议大于300ms且重试机制小于3次，避免过度放大请求导致雪崩
• 【强制】所有key都要设置expire失效时间，条件允许可以打散过期时间，防止集中过期

申请规范

• 【强制】禁止开通公网地址，禁止部署在公网可访问的服务器上
• 【强制】强制开启密码验证，密码长度16位，包含数字、大小写、特殊符号；
• 【强制】新实例强制端口 6379
• 【强制】新实例强制版本 Redis 6.0

解读：该版本具备完善的慢日志、审计日志、CloudDBA等功能

• 【强制】UAT实例配置可以差一点，但一定要与PROD架构类型保持一致
• 【建议】根据实际的业务需要，从如下4种规格选择：

• 【建议】申请Redis实例，需要从QPS及容量等维度评估，选择合适规格的Redis

QPS：评估三个月内的业务高峰的QPS，选择合适的集群版分片数；也可选择读写分离版
容量：根据redis的key类型、key大小、value大小估算出redis容量，可参考 [Redis评估平台](http://www.redis.cn/redis_memory)

• 【建议】短期测试使用可以选择按量付费模式

使用规范

• 【强制】不做持久化，切记Redis是用来做缓存而非数据库

解读：对于数据有持久化需求的场景，建议使用MySQL进行数据存储，不要放在Redis存储

• 【建议】冷热数据区分，建议将热数据(如QPS超过5k)的数据加载到Redis中。低频数据存储在Mysql、ElasticSearch中
• 【建议】如非必要，不建议开启SSL加密

解读：开启SSL加密，会增加Redis服务的网络响应时间、需要每年更换SSL证书(有效期一年)、更新证书有效期要重启实例(会发生秒级闪断)。

• 【强制】生产环境禁止使用keys、flushall、flushdb等命令

解读：执行这些命令，会长时间阻塞 Redis 主线程，危害极大，建议通过redis的rename机制禁掉命令，修改 redis.conf 文件，添加如下参数并重启redis：
rename-command FLUSHALL ""
rename-command FLUSHDB ""
#rename-command CONFIG ""
rename-command KEYS ""
rename-command SHUTDOWN ""
#rename-command DEL ""
rename-command EVAL ""

注1：重命名为"" 代表禁用命令，如想保留命令，可以重命名为不可猜测的字符串，如： rename-command FLUSHALL joYAPNXRPmcarcR4ZDgC
注2：若哨兵模式禁用config命令会导致无法自动切换

• 【建议】规范key的格式，以业务为前缀(防止key冲突)，用冒号分隔，便于查看、统计、排错。

upc:user:sex  //upc业务某用户的性别

• 【建议】保证语义的前提下，控制key的长度，尽可能把key定义得短一些

解读：比如 user:book:123 可以优化为 u:bk:123

• 【建议】拒绝bigkey(防止内存增长过快、网卡流量过高、慢查询)：String类型控制在10KB以内，List/Hash/Set/ZSet元素个数不要超过5000
• 【建议】若无法避免存储bigkey，建议开启lazy-free机制（4.0+版本支持）

解读：当开启lazy-free机制后，Redis 在删除一个 bigkey 时，释放内存的耗时操作，将会放到后台线程中去执行，这样可以在最大程度上避免对主线程的影响。

• 【建议】不要使用del删除非字符串的bigkey，使用hscan、sscan、zscan方式渐进式删除

解读：List类型：执行多次 LPOP/RPOP，直到所有元素都删除完成；
解读：Hash/Set/ZSet类型：先执行 HSCAN/SSCAN/SCAN 查询元素，再执行 HDEL/SREM/ZREM 依次删除每个元素；

• 【建议】注意防止bigkey过期时间自动删除问题

解读：例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞，而且该操作不会出现在慢查询中(latency可查)；

• 【建议】选择合适的数据类型

解读：使用Bloom Filter 代替hyperloglog，数据更加的精准；
解读：String、Set：尽可能存储 int 类型数据；
解读：Hash、ZSet：存储的元素数量控制在转换阈值之下，以压缩列表存储，节约内存；

• 【建议】实例设置 maxmemory + 淘汰策略，淘汰策略的选择需要结合业务特点来决定

volatile-lru / allkeys-lru：优先保留最近访问过的数据
volatile-lfu / allkeys-lfu：优先保留访问次数最频繁的数据（4.0+版本支持）
volatile-ttl ：优先淘汰即将过期的数据
volatile-random / allkeys-random：随机淘汰数据

• 【建议】预留redis进程1.5倍的可用内存，避免OOM
• 【建议】使用容量不要超过2GB，再多考虑拆分多个实例
• 【建议】使用长连接操作 Redis，合理配置连接池
• 【建议】尽管 Redis 提供了 16 个 db，但建议只使用db0

原因1：在一个连接上操作多个 db 数据时，每次都需要先执行 SELECT，这会给 Redis 带来额外的压力，这也是禁用select函数的原因；
原因2：使用多个 db 的目的是按不同业务线存储数据，那为何不拆分多个实例存储呢？
原因3：Redis Cluster只支持db0(不支持多个 database)，如果后期要迁移到 Redis Cluster，迁移成本高；

• 【建议】扩展方式首选客户端hash

解读：若单个 redis 集群满足不了性能，不要着急扩容，集群越大，在状态同步和持久化方面的性能越差。
优先使用客户端 hash 进行集群拆分。
如：根据用户 id 分 10 个集群，用户尾号为 0 的落在第一个集群。

• 【建议】读请求大推荐读写分离，写请求量大推荐分片集群
• 【建议】不开启 AOF 或 AOF 配置为每秒刷盘

解读：如果对于丢失数据不敏感的业务，建议不开启 AOF，避免 AOF 写磁盘拖慢 Redis 的性能。
如果确实需要开启 AOF，则建议配置为 appendfsync everysec，把数据持久化的刷盘操作，放到后台线程中去执行，尽量降低 Redis 写磁盘对性能的影响。

• 【建议】慎用monitor命令

解读：如果OPS比较高，那么在执行 MONITOR 会导致 Redis 输出缓冲区的内存持续增长，
这会严重消耗 Redis 的内存资源，甚至会导致实例内存超过 maxmemory，引发数据淘汰。

• 【建议】调整 maxmemory 时，注意主从库的调整顺序

解读：Redis 5.0 以下版本存在一个问题：从库内存如果超过了 maxmemory，也会触发数据淘汰。
在某些场景下，从库是可能优先主库达到 maxmemory 的（例如在从库执行 MONITOR 命令，输出缓冲区占用大量内存），那么此时从库开始淘汰数据，主从库就会产生不一致。
要想避免此问题，在调整 maxmemory 时，一定要注意主从库的修改顺序：
1.调大 maxmemory：先修改从库，再修改主库
2.调小 maxmemory：先修改主库，再修改从库
直到 Redis 5.0，Redis 才增加了一个配置 replica-ignore-maxmemory，默认从库超过 maxmemory 不会淘汰数据，才解决了此问题。

• 【建议】禁用 Lua 脚本扩展，存在性能和使用限制
• 【建议】Redis事务功能较弱，建议禁用事务
• 【建议】严禁不设置范围的批量操作

解读：redis 慢查询除了网络延迟，大多数线上问题都是由于这些批量操作函数引起。
1、[zset] 严禁对 zset 的不设范围操作
2、[hash] 严禁对大数据量 Key 使用 HGETALL
3、[key] Redis Cluster 集群的 mget 操作
4、[其他] 严禁使用 sunion, sinter, sdiff等一些聚合操作

• 【建议】Redis集群的从节点必须设置为 slave-read-only，避免从库写入数据，导致主从数据不一致。
• 【建议】部署哨兵或集群，实现故障自动切换
• 【建议】以普通用户启动 Redis 进程，禁止 root 用户启动
• 【建议】限制 Redis 配置文件的目录访问权限

设置redis的主目录权限为700,如果redis配置文件独立于redis主目录,权限修过为600,因为redis密码明文存储在配置文件中