【Redis】中的一些坑（一）——「常用命令」篇

╰+攻爆jí腚メ 2023-10-04 19:31 24阅读 0赞

> 本文需要对 Redis 常用命令、底层数据结构、内存管理以及集群等相关概念有一定了解，推荐查看 [Redis 面试题总结][Redis] 快速学习相关知识点。

### 1 前言 ###

想必大家在使用 Redis 时，或多或少遇到了一些「诡异」的场景，那很大概率是踩到「坑」：

*  一个设置了过期时间的 key 最后没有过期；
 *  使用 `O(1)` 复杂度的 `SETBIT` 命令，竟然 OOM 了；
 *  使用 `RANDOMKEY` 随机读取一个 key，主线程发生阻塞；
 *  相同命令主库查不到数据，从库却可以查到；
 *  从库使用内存为什么比主库使用的多；
 *  …

熟悉和了解一些 Redis 中的常见问题，可可以方便我们快速的定位和解决问题，经过归类整理，笔者把这些问题大致划分成三大部分：

1.  常见命令有哪些坑？
2.  数据持久化有哪些坑？
3.  主从库同步有哪些坑？

### 2 常用命令中的坑 ###

首先让我们看看哪些平常再熟悉不过的命令可能会产生「意料之外」的结果。

#### 2.1 过期时间意外丢失 ####

`SET` 命令一定是 Redis 使用最多的命令，它不仅可以设置 key-value 之外，还可以设置 key 的过期时间，就像下面这样：

127.0.0.1:6379> SET testkey val1 EX 60
    OK
    127.0.0.1:6379> TTL testkey
    (integer) 59

但需要注意的是，如果你从代码其它地方修改了这个 key，并且没有加上「过期时间」参数，那这个 key 的过期时间将会被「擦除」，即**永不过期**。

127.0.0.1:6379> SET testkey val2
    OK
    127.0.0.1:6379> TTL testkey  // key永远不过期了！
    (integer) -1

如果你发现 Redis 的内存持续增长，而且很多 key 原来设置了过期时间，后来发现过期时间丢失了，很有可能是因为这个原因导致的。

#### 2.2 **DEL 阻塞 Redis** ####

当需要删除一个 key 时你也许立马就想到了 `DEL` 命令，但你是否想过它的时间复杂度？

Redis 官方文档在介绍 DEL 命令时，是这样描述的：**删除一个 key 的耗时与其类型有关。**

*  key 是 String 类型，DEL 时间复杂度是 O(1)；
 *  key 是 List、Hash、Set、ZSet 类型，`DEL` 时间复杂度是 O(M)，M 为元素数量。

如果你了解 Redis 的底层数据结构就不难理解，所以，当**删除 List、Hash、Set、ZSet 类型的 key** 时，一定要格外注意，不能无脑执行 `DEL`，而是应该用以下方式删除\*\*：\*\*

1）查询 key 中元素数量：执行 `LLEN` `HLEN` `SCARD` `ZCARD` 命令；

2）判断 key 中元素数量：如果较少可直接删除，否则分批删除；

3）**分批删除**：执行 LRANGE/HSCAN/SSCAN/ZSCAN + LPOP/RPOP/HDEL/SREM/ZREM 删除。

上面说的是集合类型，如果直接删除一个 String 类型就不会出现这种情况吗？

**显然也会阻塞 Redis 主线程**，我们知道，一个 String 类型的 key 默认最大可以存储 512M 的数据，当 Redis 释放一个如此大的内存给操作系统时，必然也是耗时的。

如果打开 `lazy-free` 机制是否就不会阻塞主线程？

即使 Redis 打开了 lazy-free，在删除一个 String 类型的 bigkey 时，它仍旧是在主线程中处理，而不是放到后台线程中执行。所以依旧无法解决阻塞 Redis 的风险。

#### 2.3 **RANDOMKEY 阻塞 Redis** ####

Redis 提供了一个随机查看内存中一个 key 的命令： `RANDOMKEY`。这个命令会从 Redis 中「随机」取出一个 key，虽名为**随机**，但执行速度也并非我们想象中的快。

要解释清楚这个问题，就要结合 Redis 的过期策略来讲。Redis 采用**定时清理** \+ **懒惰清理**两种结合方式来清理过期 key。

再来了解一下 `RANDOMKEY` 的执行过程：Redis 在随机拿出一个 key 后，首先会先检查这个 key 是否已过期。如果该 key 已经过期，那么 Redis 会删除它，这个过程就是懒惰清理。但清理完了还不能结束，Redis 还要以此循环往复，直到找出一个「不过期」的 key 返回给客户端。

但这里就有一个问题：如果此时 Redis 中，有大量 key 已经过期，但还未来得及被清理掉，那这个循环就会持续很久才能结束，而且，这个耗时都花费在了清理过期 key + 寻找不过期 key 上。导致的结果就是，`RANDOMKEY` 执行耗时变长，影响 Redis 性能。

以上流程主要针对的是 Matser 节点，如果是 **Slave 节点执行 `RANDOMKEY` 命令那么产生的问题将更加严重**。主要原因就在于，**Slave 是不会自己清理过期 key：**

当一个 key 要过期时，Master 会先清理删除它，之后 Master 向 Slave 发送一个 `DEL` 命令，告知 Slave 也删除这个 key，以此达到主从库的数据一致性。

还是在同样 Redis 中存在大量已过期但还未被清理的 key 的场景中， Slave 上执行 `RANDOMKEY` 时就会发生以下问题：

1）Slave 随机取出一个 key，判断是否已过期；

2）key 已过期，但 Slave 不会删除它，而是继续随机寻找不过期的 key；

3）由于大量 key 都已过期，那 Slave 就会寻找不到符合条件的 key，此时就会陷入「死循环」中。

也就是说，在 Slave 上执行 `RANDOMKEY`，有可能会造成整个 Redis 实例卡死。

**这其实是 Redis 的一个 Bug，并一直持续到 5.0 才被修复。Redis 给出的解决方案是：**

在 Slave 上执行 `RANDOMKEY` 时，先判断整个实例所有 key 是否都设置了过期时间，如果是，为了避免长时间找不到符合条件的 key，Slave 最多只会在哈希表中寻找 100 次，无论是否能找到，都会退出循环。即增加了一个**最大重试次数。**

![在这里插入图片描述][5abf1a7d78c94e2aa21b64fb4db59eaa.png_pic_center]

所以，如果你在使用 `RANDOMKEY` 时发现 Redis 产生了「抖动」，很有可能是因为这个原因导致。

#### 2.4 SETBIT 导致 OOM ####

String 类型除了存储一串字符串外，我们经常还可以将其当做 bitmap 位图来使用。换句话说将 value 拆成一个一个的 bit 位来使用：

127.0.0.1:6379> SETBIT testkey 10 1
    (integer) 1
    127.0.0.1:6379> GETBIT testkey 10
    (integer) 1

但是这里有一个坑：如果这个 key 不存在，或者 key 的内存使用很小，此时你要操作的 offset 非常大，那么 Redis 就需要**分配「更大的内存空间」**，这个操作耗时就会变长，影响性能。

![在这里插入图片描述][29e276c352fb4877830a62a75174702e.png_pic_center]

所以，当你在使用 `SETBIT` 时，也一定要注意 offset 的大小，**操作过大的 offset 会引发 Redis 卡顿。当然，也要注意删除时的影响。**

#### 2.5 MONITOR 导致 OOM ####

当你在执行 `MONITOR` 命令时，Redis 会把每一条命令写到客户端的「输出缓冲区」中，然后客户端从这个缓冲区读取服务端返回的结果。

![在这里插入图片描述][b9557058114b450cb8bf7fd4c2d7e3a1.png_pic_center]

但如果 Redis 对应的 QPS 很高时，这将会导致这个输出缓冲区内存持续增长，占用 Redis 大量的内存资源，如果恰好机器的内存资源不足，那 Redis 实例就会面临被 OOM 的风险。

[Redis]: https://blog.csdn.net/adminpd/article/details/122934938?spm=1001.2014.3001.5501
[5abf1a7d78c94e2aa21b64fb4db59eaa.png_pic_center]: https://img-blog.csdnimg.cn/5abf1a7d78c94e2aa21b64fb4db59eaa.png#pic_center
[29e276c352fb4877830a62a75174702e.png_pic_center]: https://img-blog.csdnimg.cn/29e276c352fb4877830a62a75174702e.png#pic_center
[b9557058114b450cb8bf7fd4c2d7e3a1.png_pic_center]: https://img-blog.csdnimg.cn/b9557058114b450cb8bf7fd4c2d7e3a1.png#pic_center