标签：缓存 Redis redis 面试 key 高频 下线 节点

文章目录

• 1.redis是什么？
• 2.redis怎么使用？
• 3.应用场景
• • String
  • List(双向链表)
  • hash(hashmap)
• 4.为什么redis是单线程还这么快
• 5.redis 也可以进行发布订阅消息吗？
• 6.redis能否将数据持久化，如何实现？
• • RDB持久化原理
  • AOF持久化原理
• 7.主从复制模式下，主挂了怎么办?
• 8.哨兵模式实现原理？（2.8 版本或更高才有）
• • 1.三个定时监控任务
  • 2.主客观下线：
  • 3.选举出某一哨兵节点作为领导者来进行故障转移
• 9.redis 集群
• 10.缓存更新策略（即如何让缓存和 mysql 保持一致性）？
• • 10.1 key 过期清除（超时剔除）策略
  • 10.2 Redis 的内存淘汰策略
• 12.如何防止缓存穿透？
• 13.无底洞优化？
• 14.雪崩优化

1.redis是什么？

redis 是 nosql(也是个巨大的 map) 单线程，但是可处理 1 秒 10w 的并发（数据都在内存中）

使用 java 对 redis 进行操作类似 jdbc 接口标准对 mysql，有各类实现他的实现类，我们常用的是 druid
其中对 redis，我们通常用 Jedis(也为我们提供了连接池 JedisPool)
在 redis 中,key 就是 byte,redis 的数据结构(value):
String,list,set,orderset,hash
每种数据结构对应不同的命令语句~

2.redis怎么使用？

先安装好 redis，然后运行，在 pom 文件中引入依赖，在要使用 redis 缓存的类的 mapper.xml 文件配置redis 的全限定名。引入 redis 的 redis.properties 文件（如果要更改配置就可以使用）

3.应用场景

String

• 存储 json 类型对象
• 计数器
• 视频点赞等

List(双向链表)

• 可以使用 redis 的 list 模拟队列,堆,栈
• 朋友圈点赞(一条朋友圈内容语句,若干点赞语句)

hash(hashmap)

• 保存对象
• 分组

4.为什么redis是单线程还这么快

1. .数据存于内存
2. 用了多路复用 I/O
3. 单线程

5.redis 也可以进行发布订阅消息吗？

可以（可以引出哨兵模式，就是因为每隔 2秒哨兵节点会发布对某节点的判断和自身的信息到某频道，每个哨兵订阅该频道获取其他哨兵节点和主从节点的信息，以达到哨兵间互相监控和对主从节点的监控）和很多专业的消息队列系统（例如 Kafka、RocketMQ）相比，Redis 的发布订阅略显粗糙，例如无法实现消息堆积和回溯。但胜在足够简单。

6.redis能否将数据持久化，如何实现？

能，将内存中的数据异步写入硬盘中，两种方式：RDB（默认）和 AOF

RDB持久化原理

通过 bgsave 命令触发，然后父进程执行 fork 操作创建子进程，子进程创建 RDB 文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换（定时一次性将所有数据进行快照生成一份副本存储在硬盘中）

优点:是一个紧凑压缩的二进制文件，Redis 加载 RDB 恢复数据远远快于 AOF的方式
缺点：由于每次生成 RDB 开销较大，非实时持久化

AOF持久化原理

开启后，Redis 每执行一个修改数据的命令，都会把这个命令添加到 AOF 文件中

优点：实时持久化
缺点：所以 AOF 文件体积逐渐变大，需要定期执行重写操作来降低文件体积，加载慢

7.主从复制模式下，主挂了怎么办?

哨兵模式（高可用）

何谓哨兵模式？就是通过哨兵节点进行自主监控主从节点以及其他哨兵节点，发现主节点故障时自主进行故障转移

8.哨兵模式实现原理？（2.8 版本或更高才有）

1.三个定时监控任务

1. 每隔 10s，每个 S 节点（哨兵节点）会向主节点和从节点发送 info 命令获取最新的拓扑结构
2. 每隔 2s，每个 S 节点会向某频道上发送该 S 节点对于主节点的判断以及当前 Sl 节点的信息
3. 每隔 1s，每个 S 节点会向主节点、从节点、其余 S 节点发送一条 ping 命令做一次心跳检测(心跳检测机制)，来确认这些节点当前是否可达

2.主客观下线：

1. 主观下线：根据第三个定时任务对没有有效回复的节点做主观下线处理
2. 客观下线：若主观下线的是主节点，会咨询其他 S 节点对该主节点的判断，超过半数，对该主节点做客观下线

3.选举出某一哨兵节点作为领导者来进行故障转移

选举方式：raft算法。每个 S 节点有一票同意权，哪个 S 节点做出主观下线的时候，就会询问其他 S 节点是否同意其为领导者。获得半数选票的则成为领导者。基本谁先做出客观下线，谁成为领导者。

9.redis 集群

1. .Redis 集群内节点通过 ping/pong 消息实现节点通信，消息不但可以传播节点槽信息，还可以传播其他状态如：主从状态、节点故障等。因此故障发现也是通过消息传播机制实现的，主要环节包括：主观下线（pfail）和客观下线（fail）
2. 主客观下线：
   2.1 集群中每个节点都会定期向其他节点发送 ping 消息，接收节点回复 pong 消息作为响应。
   如果通信一直失败，则发送节点会把接收节点标记为主观下线（pfail）状态
   2.2 客观下线：超过半数，对该主节点做客观下线
3. 主节点选举出某一主节点作为领导者，来进行故障转移
4. 故障转移（选举从节点作为新主节点）

10.缓存更新策略（即如何让缓存和 mysql 保持一致性）？

10.1 key 过期清除（超时剔除）策略

惰性过期（类比懒加载，这是懒过期）：只有当访问一个 key 时，才会判断该 key是否已过期，过期则清除。
定期过期：每隔一定的时间，会扫描一定数量的数据库的 expires 字典中一定数量的 key，并清除其中已过期的 key。

10.2 Redis 的内存淘汰策略

Redis 的内存淘汰策略是指在 Redis 的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。

noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key。
allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。
volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用key。
volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 key。
volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 key 优先移除。

12.如何防止缓存穿透？

（缓存穿透指的是查询一个根本不存在的数据，缓存层不命中，又去查存储层，又不命中。但如果有大量这种查询不存在的数据的请求过来，会对存储层有较大压力）

穿透：将一份key作两次缓存，双缓存策略.

13.无底洞优化？

造成原因：redis 分布式越来越多，导致性能反而下降，因为键值分布到更多的节点上，所以无论是 Memcache 还是 Redis 的分布式，批量操作通常需要从不同节点上获取，相比于单机批量操作只涉及一次网络操作，分布式批量操作 会涉及多次网络时间。 即分布式过犹不及。

14.雪崩优化

如果缓存层由于某些原因不能提供服务，于是所有的请求都会达到存储层，存储
层的调用量会暴增，造成存储层也会级联宕机的情况。

雪崩：可以设置Redis cache(卡时)的过期时间，让缓存失效的时间尽量均匀

标签：缓存,Redis,redis,面试,key,高频,下线,节点
来源： https://blog.csdn.net/m0_46596133/article/details/120727304

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。