一、常见命令
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】
-
master 随机取出一个 key，判断是否已过期
-
如果 key 已过期，删除它，继续随机取 key
-
以此循环往复，直到找到一个不过期的 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 个阶段：
-
3.2 以下版本，key 过期未被清理，无论哪个命令，查询 slave，均正常返回 value
-
3.2 - 4.0.11 版本，查询数据返回 NULL，但 EXISTS 依旧返回 true
-
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写请求量很大
