java八股文-redis

金三银四,准备面试,八股文少不了

1. 具体什么场景用过redis?

           我在项目中主要使用redis缓存热点数据,和用来保存授权信息

•   缓存热点数据,因为我们是一个仪表盘的项目,数据量非常大,每天上千万条日志需要汇总分析,页面需要展示指定时刻的趋势图表等,所以使用redis提前缓存数据,解决查询速度过慢的问题.
•   还有就是项目中用redis存储了,验证码生成的token信息,用来对每次请求数据权限的校验.

2. 缓存的三兄弟,怎么解决?

2.1穿透 ：

查询一个不存在的数据，查不到redis也不会存，导致每次都请求（恶意攻击）

2.1.1解决

1.就是每次查询的空数据也进行缓存（存储压力大，数据不一致问题）

2.布隆过滤器（关键点就是先经过布隆，过滤器就是一个bitmap位图，越大约不容易误判，使用时候需要预热，加载热点数据，比上面占用内存少，单存在误判）

3.bitmap 以bit为单位的数组，每个单元只能存储0,1，存储压力较小，太小容易误判

2.2 击穿

       热点key设置过期时间，过期时候正好来了大量请求

2.2.1解决：

1.互斥锁

2.逻辑过期

2.3 雪崩

      同一个时段内大量key过期，或者redis宕机

3. redis作为缓存，mysql数据如何与redis进行同步？

    业务场景 : 先说下自己业务场景,如我们是最终一致性,使用定时任务定时同步mysql数据到redis.

3.1 双写一致

1. 先删除缓存还是先修改数据库都会有问题，多线程访问会有问题
2. 为什么删除两次，因为删除一次可能，来一个线程又读取进来，所以等数据库写完在删除一次。
3. 问什么延迟，数据库主从一致，等写库完成，并不能根除，只能减少

3.2 加锁保证数据强一致性

• 分布式锁，慢，读都加锁
• 读写锁 ，读加锁，但是其他线程可以访问，写不可以；
• 写锁，获取后 其他线程不可以读写

3.3. 最终一致性，可以暂时不一致

3.4 谈谈自己使用的那个

3.5 针对自己说的业务回答，如何实现

4. redis 持久化 (RDB 数据快照,AOF操作日志)

4.1 RDB

执行原理：

rdb 默认开启 

关闭需要注释掉 save

4.2 AOF

4.3 对比

4.4 混合持久化

    4.4.1 什么是

• 混合持久化是在 AOF 持久化的基础上，定期进行 RDB 持久化，以保证数据的快速恢复
• 实现方式是在aof重写时,将rdb文件以二进制格式压缩写入aof开头,之后数据再以aof格式追加到文件的末尾

4.4.2 混合持久化的优点是：

• 可以减少 AOF 文件的大小，节省磁盘空间
• 可以加快数据恢复的速度，避免执行大量的 AOF 命令
• 可以避免数据丢失，因为 RDB 文件和 AOF 文件都有最新的数据快照

4.4.3 如何开启

    要开启混合持久化，需要在 redis.conf 文件中设置以下参数：

appendonly yes 开启 AOF 持久化

aof-use-rdb-preamble yes 开启混合持久化

开启混合持久化后，可以通过以下命令触发 AOF 重写：

bgrewriteaof 在后台执行 AOF 重写

config set auto-aof-rewrite-percentage <percentage> 设置 AOF 文件增长百分比阈值，当达到该阈值时自动执行 AOF 重写

config set auto-aof-rewrite-min-size <size> 设置 AOF 文件增长最小字节数阈值，当达到该阈值时自动执行 AOF 重写

4.4.4 如何恢复混合持久化的数据

• 恢复混合持久化的数据和恢复 AOF 持久化的数据过程是一样的，只需要把 appendonly.aof 文件放到 redis 的根目录，在 redis 启动时，只要开启了 AOF 持久化，redis 就会自动加载并恢复数据
• 恢复混合持久化的数据的步骤是：
  • 首先读取 AOF 文件中的 RDB 部分，将其中的键值对加载到内存中
  • 然后读取 AOF 文件中的 AOF 部分，按顺序执行其中的命令，更新内存中的数据

4.4.5 混合持久化的注意事项

• 混合持久化虽然有很多优点，但也有一些需要注意的地方：
  • 如果 RDB 部分损坏或丢失，那么整个 AOF 文件都无法恢复数据
  • 如果 AOF 部分损坏或丢失，那么只能恢复 RDB 部分的数据，可能会有一些数据丢失
  • 如果在执行 AOF 重写时发生故障或中断，那么可能会导致旧的 AOF 文件被覆盖或删除，造成数据丢失
• 因此，在使用混合持久化时，需要定期备份 AOF 文件，以防止数据丢失

4.5 你们项目怎么用? 

        使用混合持久化

5. 数据过期策略

5.1 数据过期后，key会立即删除吗

     过期后的删除，看策略配置

5.2 惰性删除

1. 设置key的过期时间后，不管了就，只有在使用这个可以的时候，才会检查

• Cpu友好，只有使用这个key的时候才会去检查
• 内存不友好，过期的，一直不使用的key，一直在内存中

5.3 定期删除

  5.3.1每隔一段时间，就对一些可以检查，删除过期的（随机取key，删除过期）

• Slow模式是定时任务，默认频率10hz，每次不超过25ms，调整热第四。config
• Fast执行模式不固定，两次间隔不少于2ms，每次耗时不少于1ms
• 优点 :有效释放过期键占用内存
• 缺点: 难以确定删除操作的执行时长频率

  5.3.2 使用

每隔一段时间执行一次删除过期key操作(在redis.conf配置文件设置hz，1s刷新的频率)，对一些 key 进行采样检查，检查是否过期，如果过期就进行删除。

5.4 redis采用哪种

redis 采用两种配合

6.redis的数据淘汰策略（缓存过多，内存有限，占满怎么办）

redis.conf。设置可以 # maxmemory-policy noeviction

或者命令行 CONFIG SET maxmemory-policy allkeys-lru

，修改配置文件后，需要重启 Redis 服务才能使新的配置生效。而使用命令行工具或客户端修改配置则可以立即生效，不需要重启 Redis。

6.1默认策略

嗯，这个在redis中提供了很多种，默认是noeviction，不删除任何数据，内

部不足直接报错是可以在redis的配置文件中进行设置的

6.2 最少最近使用 LRU

LRU的意思就是最少最近使用，用当前时间减去最后一次访问时间，这个值

越大则淘汰优先级越高。

数据库有1000万数据 ,Redis只能缓存20w数据, 如何保证Redis中的

数据都是热点数据 ?

可以使用 allkeys-lru （挑选最近最少使用的数据淘汰）淘汰策略，那留下来

的都是经常访问的热点数据

5.3 最少频率使用 LFU

LFU的意思是最少频率使用。会统计每个key的访问频率，值越小淘汰优先级

越高

6.4 使用建议

7. 分布式锁，如何实现

7.1 项目中使用，例如抢优惠券

7.2 加锁的话一个服务还好，多个有问题

7.3 分布式锁

7.4分布式锁原理

7.4.1 设置过期时间，防止死锁；一句命令执行，保证原子性

7.4.2 如何合理控制锁的时长，比如该过期了，但是业务还没执行完？看门狗

• redisson有看门狗会监听锁，还在执行会做续期，默认10秒
• 新来人想获取锁会循环，可以设置阈值
• 加锁，过期等给予lua脚本完成，保证原子性

7.5 redisson实现的分布式锁可以重入吗？

   可以 ；判断是否同一个线程，线程有唯一id

7.6 redisson能保证主从数据的一致？

redlock解决 性能差 很少使用

1 加锁后，主节点宕机还未同步从节点，从节点成为主节点，导致获取相同所

2. 红所可以解决 但是性能差，运维难

3. 一般不使用 ，小概率事件

8. redis的集群 

8.1. 主从复制

• 如何主从数据同步 全量同步：

注意，第一次的话会生成rdb同步，之后追加backlog

• 主从增量同步

8.2 哨兵模式 （主从模式，主节点挂了，丧失写能力），

• 哨兵模式。提供哨兵实现主从模式的故障恢复

• 服务状态监控

• 哨兵模式会出现脑裂问题

主节点没有挂，但是哨兵访问不通，就会选举一个新的主节点，那导致了两个主节点，这导致客户端连接旧的，网络恢复后旧的master降级slave，数据丢失

8.3 你们的redis 单节点还是集群

答 ：是主从（一主两从）＋3哨兵，但节点不超过１０Ｇ内存（做缓存，村存热点数据）单节点的写操作８万并发，读操作１０万并发，如果不够可以搭建多套给其它服务使用，一般够用了

8.4 分片集群

• 主从解决高可用,高并发问题
• 分片 解决海量数据问题,高并发写问题
• 这样集群有多个master,每个master保存不同数据(解决海量数据问题)
• 每个master可以有多个slave(解决 高并发写)
• master之间通过ping检测彼此健康状况

9. 常见面试题

9.1 redis单线程,为啥快?

9.2 IO多路复用

9.3 redis网络模型

可以看出,有两块用多线程,网络,和命令解析,但是命令执行还是单线程