1.说说什么事redis

Redis是一种基于键值对的NoSql数据库。
Redis中的value支持string（字符串）、hahs（哈希）、list、set、zset（有序集合）、bitmaps（位图），HyperLoglog等数据结构

2.redis可以用来干啥

3.Redis的5中数据结构

1. String类型：主要使用场景 缓存功能、计数、共享session、限速
2. hash类型是指键值本身又是一个键值对 ，使用场景：缓存用户信息，缓存对象
3. list用来存储多个有序的字符串，可以充当栈和队列的角色，适用场景消息队列、文章队列
4. set保存多个字符串元素，不允许有重复的元素，是无序的。场景标签、共同关注
5. sorted set有序集合可以进行排序，和使用索引下标的不同，它可以给每个元素设置一个权重（score）作为排序的依据。使用场景用户点赞统计、用户排序
6. bit可以用作签到

4.Redis为什么那么快

单机的Redis可以支撑每秒10几万的并发

1. 完全基于内存操作
2. 使用单线程操作，避免了线程的切换和竞态产生的消耗
3. 基于非阻塞的IO多路复用机制
4. C语言的实现，优化过的数据结构，基于几种数据结构，redis做了大量的优化，性能极高

5.Redis6.0使用多线程是怎么回事

Redis6.0的多线程是用多线程来处理数据的读写和协议解析，但是Redis执行命令还是单线程的。这样做的目的是因为Redis的性能瓶颈是在IO上而非CPU，使用多线程能提升IO读写的效率，从而提高整体的Redis 性能

6.Redis的持久化方案

redis持久化分为RDB和AOF两种

• RDB持久化：是把当前的进程数据生成快照保存到硬盘的过程，触发RDB可以分为手动和自动。手动触发分别对应的是save和bgsave命令

• save命令：阻塞当前redis服务器，知道RDB过程结束，对应内存较大的实例会阻塞过长的时间，线上环境不建议使用。
• bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化由子进程负责，完成后自动结束，阻塞只发生在fork阶段，一般时间很短。

以下场景触发自动保存：

• 使用save相关配置，如save m n表示m秒内触发n次修改，自动触发bgsave。
• 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
• 执行debug，reload命令重新加载redis时候，也会自动触发save操作
• 默认情况执行shutdown命令时候，如果没有开启AOF持久化功能则自动执行bgsave命令。

AOF
AOF持久化:以独立日志的方式记录每次写命令，重启时候在重新执行AOF文件中的命令以达到恢复数据的目的。AOF主要作用是解决数据持久化的实时性，目前是redis持久化主流方式
AOF工作流程如下：命令写入、文件同步、文件重写、重启加载
流程如下：

1. 所以写入命令会追加到aof_buf(缓冲器中)。
2. AOF缓冲区根据对应的策略向硬盘做同步操作
3. 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩目的。
4. 当Redis重启的时候，可以加载AOF文件进行数据恢复

7.RDB和AOF优缺点

RDB优点
优点|1.只有一个紧凑的二进制文件dump.rdb，非常时候全量复制，备份的场景
2. 容灾性好。可以把RDB文件拷贝到远程机器中或者文件系统，用于容灾恢复
3. 恢复速度快，RDB数据恢复速度远远快于Aof的方式。

RDB缺点|
1.实时性低，RDB是每隔一段时间持久化，没法做到实时持久化，如果在这间隔时间发生故障，数据会丢失。
2.存在兼容问题，redis多个版本进化，存在低版本不能兼容新版本的问题。

AOF的优点

1. 实时性好，aof可以通过配置appendsync属性，有always每进行一次命令操作就会记录到aof文件中。
2. 通过append模式写文件，即使中途服务器宕机，也可以通过redis-check-aof工具解决数据一致性问题

AOF缺点
1.AOF的文件比RDb大，恢复速度慢
2.数据集大的时候，比RDB启动效率低。

8.RDB和AOF如何选择

• 一般来说如果想要达到媲美数据库的安全性，应该同时启用两种持久化方式。在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为这种情况下AOF保存的文件数据集要比RDB文件保存的数据集要完整。
• 如果可以接收数分钟的以内的数据丢失，那么可以只用RDB持久
• 很多用户只使用AOF持久化，但不推荐这种，因为定时生成RDB快照非常便于进行数据备份，并且RDB恢复数据速度也比AOF更加快速，此外，使用RDb还可以避免AOF的程序bug（老的不兼容新版本）
• 如果只需要数据在服务器进行运行，也可以不使用任何的持久化方式。

9.Redis数据恢复

当redis发生了故障，可以从rdb或者Aof中恢复数据，恢复过程就是把RDB或者AOF文件拷贝到Redis的数据目录下，如果使用AOF恢复，配置文件开启AOF，然后启动redis-server就可

Redis启动加载流程：

1. 判断是否开启AOF，开启AOF且存在文件，加载AOF
2. AOF关闭或者不存AOF文件在时候，加载RDB文件
3. 加载AOF/RDB文件启动后，Redis启动成功
4. AOF/RDB文件启动失败存在错误时候，打印错误信息。

10.Redis4.0的混合持久化了解吗

重启Redis我们很少使用Rbd来恢复内存状态，因为会丢失大量的使用数据，我们通常使用AOF日志重做，但是重放AOF日志性能能相对RDB来说慢很多，这样在Redis实例很大的情况下，启动需要花费很长时间。
Redis4.0为了解决这个问题带来一个新的持久化选项------混合持久化。将rdb文件的内容和增量的AOF日志文件存在一起，这里的AOF日志不再是全量日志，而是自持久化开始到持久化结束这段时间发生的增量AOF日志，通常这部分AOF日志很小。于是在Redis重启时候，可以先加载rdb的内容，然后在重放增量AOF日志就可以完全替代之前AOF全量文件重放，重启效率因此大幅度提升。

11.高可用

Redis保证高可用主要有三种方式主从、哨兵、集群

12.Redis主从复制了解吗

主从复制，是指将一台Redis 服务器的数据，复制到其他的Redis 服务器。前者称为主节点(master)，后者称为从节
点(slave)。且数据的复制是 单向 的，只能由主节点到从节点。Redis 主从复制支持主从同步 和 从从同步两种，后
者是Redis后续版本新增的功能，以减轻主节点的同步负担

主从复制的作用

• 数据冗余：主从复制实现了数据的热备份，是持久化的一种
• 故障恢复：当主节点出现问题时候，可以由从节点提供服务，实现快速的故障恢复
• 负责均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，从节点提供读服务，分担服务器负载。尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis 服务器的并发量。
• 高可用基石：还是哨兵和集群实现的基础

13.Redis有几种常见的拓扑结构

1. 一主一从：一主一从结构是最简单的复制拓扑结构，用于主节点出现宕机时从节点提供故障转移支持
2. 一主多从：一主多从结构（又称为星形拓扑结构）使得应用端可以利用多个从节点实现读写分离（见图6-5）。对于读占比较大的场景，可以把读命令发送到从节点来分担主节点压力
3. 树状主从：树状主从结构（又称为树状拓扑结构）使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制。通过引入复制中间层，可以有效降低主节点负载和需要传送给从节点的数据量
   

14.Redis主从复制原理

1 保存主节点信息ip和端口
2. 主从建立连接：从节点发现新的主节点后，会尝试和主节点建立网络连接
3. 发送ping命令：连接建立成功后从节点发送ping请求进行首次通信，主要是检测主从之间网络套接字是否可用、主节点当前是
否可接受处理命令。
4.权限验证：如果主节点要求密码验证，从节点必须正确的密码才能通过
5.同步数据集，主从连接正常通信后，主节点会把持有的数据全部发送给从节点
6.命令持续复制，接下来主节点会持续的将写命令发送给从节点，保证主从数据一致。

15.说说主从数据同步的方式

Redis在2.8以上的版本使用psync命令完成主从数据同步，同步过程分为全量复制和部分复制
全量复制：一般用于初次复制场景，，当数据量较大时，会对主从节点和网络造成很大的开销

1.发送psync命令进行数据同步，由于是第一次进行复制，从节点没有复制偏移量和主节点的运行ID，所以发送
psync-1。

• 主节点根据psync-1解析出当前为全量复制，回复+FULLRESYNC响应。
• 从节点接收主节点的响应数据保存运行ID和偏移量offset
• 主节点执行bgsave保存RDB文件到本地
• 主节点发送RDB文件给从节点，从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件
• 对于从节点开始接收RDB快照到接收完成期间，主节点仍然响应读写命令，因此主节点会把这期间写命令数
  据保存在复制客户端缓冲区内，当从节点加载完RDB文件后，主节点再把缓冲区内的数据发送给从节点，保
  证主从之间数据一致性。
• 从节点接收完主节点传送来的全部数据后会清空自身旧数据
• 从节点清空数据后开始加载RDB文件
• 从节点成功加载完RDB后，如果当前节点开启了AOF持久化功能， 它会立刻做bgrewriteaof操作，为了保证
  全量复制后AOF持久化文件立刻可用
  
  部分复制：
  部分复制主要是针对全量复制的过高开销做的一种优化措施，使用psync{runId}{offset}命令实现。当从节点
  （slave）正在复制主节点（master）时，如果出现网络闪断或者命令丢失等异常情况时，从节点会向主节点要求补
  发丢失的命令数据，如果主节点的复制积压缓冲区内存在这部分数据则直接发送给从节点，这样就可以保持主从节
  点复制的一致性。
• 当主从节点之间网络出现中断时，如果超过repl-timeout时间，主节点会认为从节点故障并中断复制连接
• 主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内部存在的复
  制积压缓冲区，依然可以保存最近一段时间的写命令数据，默认最大缓存1MB。
• 当主从节点网络恢复后，从节点会再次连上主节点
• 当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当作psync参
  数发送给主节点，要求进行部分复制操作。
• 主节点接到psync命令后首先核对参数runId是否与自身一致，如果一致，说明之前复制的是当前主节点；之后
  根据参数offset在自身复制积压缓冲区查找，如果偏移量之后的数据存在缓冲区中，则对从节点发送+CONTINUE响应，表示可以进行部分复制。
• 主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

16.主从同步的存在哪些问题

• 一旦主节点出现故障，就需要手动将一个从节点晋升为主节点，同时需要修改应用放的主节点地址，还需要命令其他从节点去复制主节点，整个过程都需要人工干预
• 主节点的写能力收到单机限制
• 主节点的存储能力收到单机限制

第一个是Redis的高可用问题，二三是分布式问题。

17.Redis Sentinel（哨兵）了解吗

主从复制存在没有办法自动故障转移，所以需要一个方案来完成自动转移，他就是redis sentinel 哨兵机制。

Redis sentinel由哨兵节点和数据节点两部分组成

• 哨兵节点：哨兵系统由一个或者多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据，对数据进行监控。
• 数据节点：主节点和从节点都是数据节点

在复制的基础上，哨兵实现了自动化故障恢复技术

• 监控：哨兵会不断地检查主节点和从节点是否正常
• 自动故障转移：当主节点不可用的时候，哨兵会自动开始故障转移操作，他会将失效的主节点移除，其中一个从节点升级为新的主节点，并让其他从节点复制新的主节点
• 配置提供者：客户端在初始化的时候，通过连接哨兵来获得当前Redis的主节点地址
• 通知：哨兵可以将故障转移的结果发个客户端
  其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移。而配置提供者和通知功能，则需要在与客户端的交互中才能体现

18.Redis Sentinel（哨兵）实现原理知道吗？

哨兵模式是通过哨兵节点完成对数据节点的监控、下线、故障转移

Redis sentinel通过三个定时任务完成对各个节点的监控
1.每隔10秒，每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构
2.每隔2秒，每个Sentinel节点会向Redis数据节点发送Sentinel，hello频道上发送该Sentinel节点对主节点的判断以及当前Sentinel节点的信息。
3.每隔1秒每个Sentinel节点会向主节点，从节点，其余Sentinel节点发送一条ping命令，做一次心跳检测，来确认这些节点是否可达

主观下线和客观下线
主观下线就是哨兵认为某个节点有问题，客观下线就是超过一定数量的哨兵节点认为主节点有问题。

**1.主观下线：**每个Sentinel节点每隔1秒对主节点，从节点、其他Sentinel节点发送ping命令做心跳检测，当这些节点超过dow-after-minlliseconds没有进行回复，那么就对该节点判断失败，这个行为叫做主观下线。

2.客观下线：当Sentinel下线的是主节点时，该Sentinel节点会通过Sentinel-is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断，当超过《quorum》个数，Sentinel节点认为主节点确实有问题，这是该Sentinel节点会做出客观下线的决定。

• 领导者Sentinel节点选举
  Sentinel节点直接会做一个领导者选举工作，选择一个Sentinel节点作为领导者进行故障转移的工作，Redis使用Raft算法实现领导者的选举
• 故障转移
  领导者选出的Sentinel节点负责故障转移，过程如下
  

1. 在从节点列表中选出一个节点作为新的主节点，这一步是相对复杂一些的一步
2. Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点
3. Sentinel领导者节点会向剩余的从节点发送命令，让它们成为新主节点的从节点
4. Sentinel节点集合会将原来的主节点更新为从节点，并保持着对其关注，当其恢复后命令它去复制新的主节点

19.领导者Sentinel节点选举了解吗

Redis实现Raft算法实现领导者选举

1. 每个在线的Sentinel节点都有资格成为领导者，当它确认主节点主观 下线时候，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令， 要求将自己设置为领导者
2. 收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的请求，那么将同意该请求，否则拒绝
3. 如果该Sentinel节点发现自己的票数已经大于于max（quorum，num（sentinels）/2+1），那么将成为领导者
4. 如果此过程没有选出领导者，将进入下一次选举。

20.新的主节点是怎样被挑选出来的

1. 过滤：不健康（主观下线，断线）、5秒内没有回复过的、失联超过10秒的
2. 选择slave-proority（从节点优先级）最高的从节点列表，如果存在则返回，不存在就继续
3. 选择复制偏移量最大的从节点（复制的最完整），如果存在则返回，不存在继续
4. 选择runid最小的节点。

ps：请一键三连，给个关注，我们一起进步。