redis的坑：常见命令、数据持久化、主从库同步三方面的坑（鼠标左键打开图片更清晰）

• 主题目录
  

1.常见命令的坑

过期时间意外丢失？（防止因为内存淘汰，自动擦除有效数据）

DEL 竟然也会阻塞 Redis？(分步骤去删除一个键，如果键值对太大的话)

RANDOMKEY 竟然也会阻塞 Redis？(服务器全区全服不用考虑这个，因为key不会过期)

O(1) 复杂度的 SETBIT，竟然会导致 Redis OOM？

执行 MONITOR 也会导致 Redis OOM？

2.数据持久化的坑

master 宕机，slave 数据也丢失了？（如果不能开数据持久化，那就用哨兵发起主从切换）

AOF everysec 真的不会阻塞主线程吗？(全区全服对数据要求高，所以不开，设置配置为no，缺点是有可能阻塞)

6）no-appendfsync-on-rewrite yes #当子进程在 AOF rewrite 期间，
可以让后台子线程不执行刷盘（不触发 fsync 系统调用）操作

背景：bgrewriteaof机制，在一个子进程中进行aof的重写，从而不阻塞主进程对其余命令的处理，同时解决了aof文件过大问题。

优点：子进程正在执行 AOF rewrite，这个过程会占用大量的磁盘 IO 资源，开启这个选项:这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘）

缺点：人话：在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？在linux的操作系统的默认设置下，最多会丢失30s的数据。

缺点：开启这个配置项，在 AOF rewrite 期间，
如果实例发生宕机，那么此时会丢失更多的数据，性能和数据安全性，

总结：因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no

AOF everysec 真的只会丢失 1 秒数据？(aof重写在io峰值较高时会有可能与aof阻塞，导致可能损失2秒数据)

RDB 和 AOF rewrite 时，Redis 发生 OOM？（也可以关闭内存大页）

3.主从库同步的坑

主从复制会丢数据吗？（如果只开rdb，会有损失一整段数据的风险）

同样命令查询一个 key，主从库却返回不同的结果？（只要时间正确，最新的redis已经解决了这个问题）

主从切换会导致缓存雪崩？（主从时间对就行）

master / slave 大量数据不一致？（由于从服务器套内内存，redis的5.0配置默认已经修复）

slave 竟然会有内存泄露问题？（解决方法：设置从数据库配置项，改为不可写，只可读）

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

• 转载来自kaito