使用守则

缓存作为互联网应用至关重要的基础组件之一，每天承载着巨大的业务请求量。一旦缓存出现故障，对业务的影响将非常严重。因此，必须要确保缓存的稳定性。

下面是缓存使用的守则。

在保证语义的前提下，控制 key 的长度。

比如：以业务名 (或数据库名) 为前缀 (防止 key 冲突)，用冒号分隔，同时不要包含特殊字符。如

业务名:表名:id

查询 bigkey 会导致流量过高。如果出现限流，会导致业务不可用。

string 类型控制在 10 KB 以内，hash、list、set、zset 元素个数不要超过 5000 个

禁用 keys * 命令，不使用 hgetall、smembers 等命令。在获取 key 下的多个元素时，使用对应数据结构的 scan 命令，一次获取少量元素，分多次获取，一次 scan 不要超过 200 个。

最好对 key 都设置过期时间，并且将 key 的 ttl 打散，避免 key 集中过期出现业务问题。

热 key 会导致数据倾斜，还有可能导致单节点压力过大。建议业务侧将热 key 打散。

限制 mset、mget、hmset、hmget、*scan、*range 等命令单次操作元素数量，建议不要超过 200。

Redis 删除 key 时，不要用 del 命令，使用 unlink 命令。unlink 命令可以异步删除 key，减少删除操作的阻塞时间，不会对 Redis 主线程产生影响。

如：del 一个大 key 会直接导致 Redis 卡住。unlink 不会出现这种问题。

使用 setex 而不是 set 和 expire 命令，减少服务端写压力。

如果 value 较大时，使用压缩工具（如 snappy 或 gzip），把数据压缩后再写入缓存。

批量任务、定时任务、周期任务业务中要做限速

不同业务的数据使用不同的集群，过多业务复用同一资源要做拆分。业务尽量提供 rpc 接口给其它业务调用，而不是直接让其它业务访问数据源（如一个业务写，另一个业务读）

控制 pipeline 中命令的数量，不要超过 100 条

evalsha 会执行缓存在服务器端的脚本。减少网络 IO，同时也减小 Redis 网络 IO 压力，提高缓存性能。

可以通过实例隔离，不同业务的数据保存到不同的实例中。（只有 Redis 主从可以选择逻辑 db，集群模式默认都使用 db0）

集群模式对 lua 支持有限制，必须保证 lua 中操作的 key 被 sharding 到同一个节点。所以尽量减少对 lua 的使用

复杂逻辑放在业务代码中，而不是 lua 脚本中。