目录
一、常见问题
1、Redis的数据持久化策略有哪些
rdb和aof两种方式。
1）其中rdb为数据快照，将内存中的数据拷贝到磁盘中（存为快照文件），通过save或bgsave命令触发rdb存储。当故障重启后，通过读取快照文件，快速恢复数据存储。
2）aof存储方式为追加文件存储，文件中记录redis写命令。
配置文件触发策略：apendfsync always / apendfsync everysec （将写命令存储到aof缓冲区，每隔一秒将缓冲区的数据存储到文件中，因此可能会缺失一秒数据）/ apendfsync no
aof重写机制：aof记录的是操作命令，会存在很多冗余命令，可以通过bgrewriteaof命令，删除冗余命令，从而压缩aof的文件
两种方式优缺点对比：
rdb恢复数据速度快、但存储时间间隔较长，存在缺失数据的情况。
aof宕机恢复速度慢，但数据完整性较高。文件体积会比较大。
默认配置是开启rdb，关闭aof。实际应用场景中，往往两者结合使用，rdb周期性的定点备份数据。
【精选】Redis持久化的两种方式：RDB与AOF（详解）_rdb和aof_PeakXYH的博客-CSDN博客
2、什么是缓存穿透，怎么解决
请求查询缓存和数据库都不存在的数据，使db压力瞬间变大。
解决方案：
1）接口过滤，过滤掉例如id=-122等无效访问，以及加上权限过滤的方式等
2）对请求空值的数据进行缓存，例如请求不存在的id=43的数据，则在redis中缓存该条数据（值为空值），但需要注意：key设置的过期时间不能太长
3）布隆过滤器
3、什么是布隆过滤器
通过一组hash函数，将查询的入参散列到列表的不同地址，若列表地址的值均为1，则表示入参存在。通过布隆过滤器校验后，允许查询缓存、数据库。
4、什么是缓存击穿，怎么解决
某条数据在redis中过期，正好大量用户访问该热点数据，导致db压力变大（类似缓存雪崩？）
互斥锁：setnx
解决方案：
1）设置互斥锁，缓存过期后，线程一查询时获取锁，查询到数据后重新设置缓存，再释放锁。其他线程在锁住状态时，则循环休眠重试从redis获取数据。
2）逻辑设置缓存的过期时间。线程一进来后发现缓存已过期，获取互斥锁，锁获取成功，则开启新线程更新缓存，线程一则直接先返回过期数据。其他线程进入，查询缓存已过期且获取互斥锁失败，也直接返回过期数据。
Redis缓存击穿问题及解决思路_缓存击穿怎么解决-CSDN博客
5、什么是缓存雪崩，怎么解决
大量缓存在同一时间失效，大量用户请求进来，瞬间耗尽数据库资源，导致数据库无法使用。
解决方案：
缓存的有效期设置随机值，避免同一时间失效
6、redis双写问题
线程一删除redis中数据；线程二此时查询数据绕过缓存直接查询数据库，又将数据存在了缓存中。
1） 延迟双删：保持最终一致性，非强一致性。延迟时间不好确定
2）强一致性的解决方案：
加分布式锁，通过redisson提供的读写锁，readlock（共享锁）读数据，writelock（排它锁）写数据。
3）延迟一致性的解决方案：
a、通过异步消息通知实现。发送更新缓存的通知到mq，mq执行更新缓存的操作。
b、通过canal监听mysql数据库的binlog日志，canal通知数据变更，业务服务更新数据。
7、Redis分布式锁如何实现
基于redisson通过实现设置锁，底层原理是用setnx+lua。
redisson实现的锁是可重入锁。实现的锁不是主从强一致性。
主从一致性的话，有个redlock锁（使用时官方推荐至少5个实例master）
8、Redis实现分布式锁如何合理的控制锁的有效时长
通过看门狗功能，后台启动线程实时监控锁的过期状态，延长锁的有效时间。
9、Redis的数据过期策略有哪些
1、主动删除：redis定期扫描key，删除过期数据
2、被动删除：key在被操作的时候，检查是否过期，过期则删除数据
10、Redis的数据淘汰策略有哪些
八种：
1、noeviction: 不淘汰，数据满了后不再写入数据。默认这个策略
2、volatile-ttl, key到期时间最短的先淘汰
3、allkeys-random，随机淘汰key
4、volitile-random，随机淘汰设有失效时间的key
5、allkeys-lru，所有key进行lru算法淘汰
6、allkeys-lfu，所有key进行lfu算法淘汰
7、volitile-lru，失效时间的key进行lru算法淘汰
8、volitile-lfu，失效时间的key进行lfu算法淘汰
二、其他问题
1、Redis集群有哪些方案,知道嘛
主从复制、哨兵模式、分片集群
2、什么是Redis主从同步
通过主从同步读写分离，往主节点写入数据，从从节点同步数据。其中就要保证主从节点的数据同步。
全量复制同步流程：
1、从节点向主节点发起同步的请求，主节点判断是否第一次同步数据，是第一次则返回replyid（版本号）和offset（偏移值），从节点保存版本号和偏移值。
2、主节点另启线程，通过bgsave的方式生成rdb文件，发送给从节点。从节点清空数据后，执行rdb文件
3、主节点生成rdb文件的时间段中，若有新的数据产生，则通过追加命令的方式加载到缓冲区，待第二步骤结束后，发送repl_baklog文件到从节点，从节点执行
增量复制：
1、从节点发起同步请求，主节点判断是否第一次同步数据，不是第一次，则从repl_baklog中获取offset后的数据，发送到从节点
3、你们使用Redis是单点还是集群?哪种集群
集群，一主一从+哨兵模式。
4、Redis分片集群中数据是怎么存储和读取的
不太清楚，只知道通过hash散列到redis的不同槽？
5、redis集群脑裂
主节点和从节点处于不同的网络分区，当主节点网络通信异常时，sentinel检测不到主节点的心跳，认为主节点已经下线，重新选出一个从节点提到新的主节点。但实际主节点并未真实下线，仍在进行业务数据写入。等网络恢复后，由于已经选出了新的主节点，原先的主节点被降为从节点，主从同步数据时，新主节点向从节点写入数据，出现数据丢失的情况。
如何避免：
修改redis配置，设置最小主从节点数，主节点至少有一个从节点才能执行写入命令。
修改数据同步延迟时间，缩短时间。
两者组合，保证在网络故障时间，主节点不允许写入客户端消息。
6、怎么保证redis的高并发高可用
通过哨兵模式检测集群的运行状态，自动故障恢复。
7、你们用过Redis的事务吗?事务的命令有哪些
不知道
8、Redis是单线程的，但是为什么还那么快?
redis是基于内存的，单线程执行。
187
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
