一、常见命令

1.1 过期时间意外丢失

原因：

SET命令如果不设置过期时间，那么Redis会自动【擦除】这个key的过期时间

1.2 DEL命令阻塞redis

• key是String类型时，DEL时间复杂度是O(1)
• key是List/Hash/Set/ZSet类型，DEL时间复杂度是O（M），M为元素数量

1.3 RANDOMKEY阻塞redis

RANDOMKEY命令会从redis中随机取出一个key，首先会检查这个key是否过期，如果已经过期，那么Redis会删除它，这个过程就是懒惰清理；

清理完之后，redis还要找出一个【不过期】的key，返回给客户端。

整个流程就是这样的：【在master执行RANDOMKEY】

1. master 随机取出一个 key，判断是否已过期

2. 如果 key 已过期，删除它，继续随机取 key

3. 以此循环往复，直到找到一个不过期的 key，返回

如果有大量key已经过期，还没来得及清理，这个循环就卡住了，耗时都花费在了清理过期key+寻找不过期key上。

【slave执行RANDOMKEY】

slave是不会主动清理过期key的，当一个key要过期时，master会先清理删除它，然后向slave发送一个DEL命令，告知slave也需要删除这个key，以此达到主从库的数据一致性。

1.4 SETBIT导致redis OOM

在使用setbit时，需要注意offset的大小，操作过大的offset也会引发redis的卡顿

1.5 MONITOR导致redis OOM

当执行monitor命令时，redis会把每条命令写到客户端的【输出缓冲区】中，然后客户端从这个缓冲区读取服务器返回的结果。

如果redis的QPS很高，会导致这个输出缓冲区内存持续增长，占用redis大量的内存资源，如果机器资源内存不足，将会面临OOM的风险。

二、数据持久化

两种持久化方式，rdb和aof

rdb是数据快照，而aof会记录每一个写命令到日志文件中。

2.1 master宕机，slave数据也跟着丢失

如果redis采用如下模式部署，就会发生数据丢失的问题

• master-slave+哨兵部署实例
• master没有开启数据持久化功能
• Redis进程使用supervisor管理，并配置为【进程宕机，自动重启】

此时，如果master宕机，就会导致如下问题：

• master宕机，哨兵还未完成切换，此时master进程立即被supervisor自动拉起
• 但是master没有开启任何数据持久化，启动后是一个【空】实例
• 此时slave为了跟master保持一致，会自动清空实例中的所有数据，导致slave也成了一个空实例

这样master和slave中的数据就全部丢失了。

这时，业务应用访问redis时，发现缓存中没有任何数据，就会把请求全部打到后端数据库中，进一步引发缓存雪崩，对业务影响非常大。

改进：

• redis实例不使用进程管理工具自动拉起
• master宕机后，让哨兵发起切换，把slave提升为master
• 角色切换完成后，再重启master，使其退化为slave。

2.2 AOF everysec真的不会阻塞主线程吗？

这种方案的工作方式为：

redis后台线程每隔1秒，就会把AOF中的数据刷到磁盘上。【把aof刷盘的耗时操作，放到了后台子线程中去执行，避免了对主线程的影响】

刷盘流程：

• 主线程在写 AOF page cache（write系统调用）前，先检查后台 fsync 是否已完成？

• 后台 fsync已完成，主线程直接写AOF page cache

• 未完成，则检查距离上次fsync过去多久？

• 距离上次fsync成功在2秒内，那么主线程会直接返回，不写AOF page cache

• 距离上次fsync成功大于2秒，主线程强制写AOF page cache

• 由于磁盘IO负载过高，此时后台线程fsync会发生阻塞，那主线程在写AOF page cache时，也会发生阻塞等待（操作同一个 fd，fsync 和 write 是互斥的，一方必须等另一方成功才可以继续执行，否则阻塞等待）

即使配置的AOF刷盘策略是everysec，也依旧会有阻塞主线程的风险。

原因：磁盘IO负载过高导致fsync阻塞，进而导致主线程写AOF page cache也发生阻塞。

2.3 AOF everysec真的只会丢失1秒数据？

参考步骤4，后台线程在执行fsync刷盘时，主线程最多等待2秒不会写AOF page cache.

如果此时 Redis 发生了宕机，那么，AOF 文件中丢失是 2 秒的数据，而不是 1 秒！

为什么主线程会等待2秒不写AOF page cache？

• 降低主线程阻塞的风险【如果无脑写AOF page cache，主线程会立即阻塞住】
• 如果fsync阻塞，主线程就会给后台线程留出1秒的时间，等待fsync成功

2.4 RDB和AOF rewrite时，Redis发生OOM

redis在把RDB快照和AOF rewrite时，会采用创建子进程的方式，把实例中的数据持久化到磁盘上。

创建子进程时，会调用操作系统的fork函数，fork执行完成后，父进程和子进程会同时共享同一份内存数据。

此时父进程依旧是可以接收写请求的，而进来的写请求，会采用Copy On Write(写时复制)的方式操作内存数据。【先拷贝再修改，这里需要拷贝原有的内存数据到新内存中】

如果业务特点是【写多读少】，且OPS非常高，在RDB和AOF 的rewrite期间，就会产生大量的内存拷贝工作，这期间修改key的范围越广，新申请的内存就越多，如果机器资源不足，就会面临OOM的风险

三、主从库同步

3.1 主从复制会丢数据吗？

会,redis的主从复制时采用【异步】方式进行的。

如果master突然宕机，可能会有部分数据未同步到slave的情况。

3.2 同样命令查询一个key，主从库却返回了不同的结果

如果一个key已经过期，但是这个key还未被master清理，此时在slave上查询这个key，会返回什么结果？

返回结果取决于以下因素：

• redis版本【3.2以下版本，在slave上查询一个key时，并不会判断这个key是否已经过期，而是无脑返回给客户端结果】
• 具体执行的命令
• 机器时钟【根据本机时钟判断是否过期】

slave 查询过期 key，经历了 3 个阶段：

1. 3.2 以下版本，key 过期未被清理，无论哪个命令，查询 slave，均正常返回 value

2. 3.2 - 4.0.11 版本，查询数据返回 NULL，但 EXISTS 依旧返回 true

3. 4.0.11 以上版本，所有命令均已修复，过期 key 在 slave 上查询，均返回「不存在」

3.3 主从切换导致缓存雪崩

如果slave的机器时钟比master快很多，从slave的角度来看，redis中的数据存在大量过期。

此时如果操作【主从切换】，把slave提升为新的master，成为master后就会开始大量清理过期key，就会导致以下结果：

• master大量清理过期key，主线程发生阻塞，此时无法处理客户端请求
• redis中数据大量过期，引发雪崩

当 master / slave 机器时钟严重不一致时，对业务的影响非常大！

所以，如果你是 DBA 运维，一定要保证主从库的机器时钟一致性，避免发生这些问题。

3.4 master/slave大量数据不一致

redis的maxmemory配置可以控制整个实例的内存使用上限，超过这个上限，并且配置了淘汰策略，那么实例就开始淘汰数据。

如果master/slave配置的maxmemory不一样，那此时就会发生数据不一致。

5.0版本增加了一个配置项：replica-ignore-maxmemory，默认 yes

3.5 slave竟然有内存泄漏的问题

redis内存泄漏

• redis使用的是4.0以下版本
• slave的配置项为read-only=no（从库可写）
• 向slave写入了有过期时间的key

这时的 slave 就会发生内存泄露：slave 中的 key，即使到了过期时间，也不会自动清理。

如果你不主动删除它，那这些 key 就会一直残留在 slave 内存中，消耗 slave 的内存。

最麻烦的是，你使用命令查询这些 key，却还查不到任何结果！

4.0以上版本修复了这个问题

最好的方案是：

制定一个redis使用规范，slave必须强制设置为read-only，不允许写，这样不仅可以保证master/slave的数据一致性，还避免了slave内存泄漏的问题。

3.6 为什么主从全量同步一直失败

redis的【复制风暴】

主从全量同步失败，又重新开始同步，之后又同步失败，以此往复，恶性循环，持续浪费机器资源。

导致该问题的原因：

• master的实例数据过大，slave在加载RDB时耗时过长
• 复制缓冲区配置过小
• master写请求量很大