Redis 实用小技巧——浅谈 Redis 使用规范

快乐的皮拉夫的个人博客 / 474 / 8 / 创建于 7个月前 / 更新于 7个月前

简介

我们都知道，Redis 作为一款基于内存的「非关系型数据库」，无论是作为缓存还是其他高并发的场景的数据库存储，都有着得天独厚的优势。而 Redis 的优势，主要体现在以下几个方面：

极快的读写速度
丰富的数据类型
操作的原子性
丰富的特性

正所谓「好钢用在刀刃上」。要想充分发挥 Redis 的优势，各种规范问题也就显得尤为重要。本篇文章，我们就来聊一聊关于 Redis 使用规范中需要注意的一些问题。

话不多说，准备发车～

规范说明

一、键命名规范

大小写保持一致（建议使用全部大写的格式，非强制要求）
键名称的长度保持适中（太长占用过多内存资源，太短可读性太差）
合理使用命名空间，每一级之间使用 : 进行分隔，如果是复合单词，单词之间使用 _ 进行分隔。一般按照 项目标识:模型标识:字段标识:标识ID 进行命名。比如在 CMS 系统中，我们需要记录用户的登录 token ，我们就可以设计如下的键：
```
CMS:USER:LOGIN_TOKEN:123
```
避免在键中使用敏感信息，以免造成信息泄露

二、合理设置过期时间

在使用 Redis 的过程中，我们一般都会给键设置过期时间。在设置过期时间时，需要注意以下规范问题：

批量设置过期时间的时候最好加一个随机值，避免「缓存雪崩」的问题
对于需要长期保留的数据（如配置信息），可以考虑直接存储在 Redis 内存中，而不设置过期时间
对于一般的缓存信息，建议设置一个相对较长的过期时间。当修改数据时，同时刷新缓存即可

三、选择合适的键类型

在之前的系列文章《Redis 实用小技巧——一文教你如何选择合适的 Key 类型》一文中详细介绍过如何选择合适的数据类型，这里仅作简单总结：

简单的字符串存储，优先考虑使用 String
如果是普通的对象属性存储，优先考虑使用 Hash
需要「先进先出」的任务场景，优先考虑使用 List
需要存储一组元素，且元素具有唯一性，优先考虑使用 Set
需要存储一组元素，且元素具有唯一性和「分值」，而且需要对元素进行排序比较，优先考虑使用 Zset

四、线上禁用或慎用高危命令

对于业务体量比较大的公司，线上 Redis 无论是数据量还是请求量都是很大的，一旦操作不当，将造成线程阻塞甚至服务不可用的情况。所以一些线上的 Redis 命令是需要禁用或者是谨慎使用的。

如果使用的是本地 Redis 服务，需要在配置文件中添加 rename-command keys "" 来禁用命令。如果使用的是 Redis 云服务器的话，需要在参数设置的禁用命令列表中添加需要禁用的命令。

KEYS 命令【禁用】

危险指数：

禁用原因：KEYS命令执行的时候是需要进行全库扫描的，如果数据库中 key 很多的话，会造成命令线程阻塞，从而导致 Redis 不可用。如果需要遍历全库的 key 的话，使用 SCAN 命令替代。

FLUSHDB、FLUSHALL 命令【禁用】

危险指数：

禁用原因：FLUSHDB 会清除指定数据库的所有 key，而 FLUSHALL 会清除所有数据库的 key。这两个命令本身就属于高危操作，如果开启的是 RDB 持久化方案的话，数据就无法恢复了。所以即使有类似需求，也需要特殊权限的运维人员进行操作。另外清空数据库的操作耗时比较长，会造成线程阻塞。

SHUTDOWN 命令【禁用】

危险指数：

禁用原因：SHUTDOWN 命令可以直接停止 Redis 服务。高危命令自然不必多说。

CONFIG 命令【禁用】

危险指数：

禁用原因： CONFIG 命令属于运维命令，可以直接修改 Redis 配置信息，因此，需要指定特殊权限的运维人员操作此命令。

DEBUG 命令【禁用】

危险指数：

禁用原因：DEBUG 命令是一个内部命令。旨在用于开发和测试 Redis，线上环境可能会造成灾难性的后果。比如下面命令，可以直接让 Redis 服务崩溃：

DEBUG SEGFAULT

EVAL 命令【慎用】

危险指数：

慎用原因：EVAL 命令用于执行 lua 脚本，在一些处理程序中直接使用 EVAL 命令执行 lua 脚本效率会更好。但是此命令需要慎重使用，如果在 lua 脚本里面构造大量循环，会导致 Redis 主进程卡死。

注意：SCRIPT LOAD + EVALSHA 命令组合也会实现 EVAL 的效果。

HGETALL 命令【慎用】

危险指数：

慎用原因： HGETALL 的时间复杂度为 O(N)， N 为哈希表的大小。也就是说，字段越多，耗时越长。类似的命令还有：LRANGE key 0 -1、SMEMBERS、ZRANGE key 0 -1等，这些集合类获取元素的命令时间复杂度都是 O(N)。所以在使用前需要先使用元素个数查询命令（如 HLEN、LLEN、SCARD、ZCARD）查看下集合元素的数量，然后再决定能否使用。

五、避免 bigkey

因为 Redis 命令是单线程执行的，所以 bigkey 的读写操作都会造成线程阻塞。因此，在日常开发中，我们需要注意，尽量从源头上避免 bigkey 的产生。

bigkey 的影响主要有以下几个方面：

阻塞请求。Redis 单线程执行命令时，对 bigkey 的读写操作会造成线程阻塞的情况。
阻塞网络。读取 bigkey 操作会占用较大的网络带宽，会影响到同节点下其他实例正常的网络通信。
内存占用变大。如果使用了集群，还会造成集群负载分布不均衡的情况。
影响主从同步，主从切换。

注意：关于如何排查数据库中的 bigkey ，感兴趣的小伙伴可以参考《Redis 实用小技巧—— key 分布情况分析》一文。

为了避免 bigkey 情况的产生，我们在日常开发中需要注意以下几点：

针对 String 类型的 key，理论上值的大小不得超过 512 MB。尽管 Redis 文档中并没有明确规定 bigkey 边界的具体大小，但是我们本着越小越好的原则，尽量控制在 KB 级别的范围内。
针对 Hash，List，Set 和 ZSet 类型的 key，理论上包含的元素数量不得超过 2^32 - 1 个，且每个元素的大小不得超过 512 MB。实际应用中，我们最好将元素的数量控制在 10000 以内，且单个元素的大小不宜过大。
定期排查数据库中 bigkey 的情况，针对 bigkey 及时做切分或者清理的处理。