Redis追命连环问，你能回答到第几问？（下）

上次的Redis连环问问到了Redis是什么，Redis支持的数据类型，缓存雪崩缓存穿透缓存击穿，内存淘汰策略和持久化策略等。

​

Redis常见面试题连环问，你能回答到第几问？（上）

Redis常见面试题连环问，你能回答到第几问？（中）

Redis常见面试题连环问，你能回答到第几问？（下）

这次来继续问：

• Redis主从复制机制

• Redis哨兵原理

• 主从复制

面试官：redis单节点存在单点故障问题，为了解决单点问题，一般都需要对redis配置从节点，然后使用哨兵来监听主节点的存活状态，如果主节点挂掉，从节点能继续提供缓存功能，你能说说redis主从复制的过程和原理吗？

我有点懵，这个说来就话长了。

但幸好提前准备了：主从配置结合哨兵模式能解决单点故障问题，提高redis可用性。从节点仅提供读操作，主节点提供写操作。

对于读多写少的状况，可给主节点配置多个从节点，从而提高响应效率。

我顿了一下，接着说：关于复制过程，是这样的：

1、从节点执行slaveof[masterIP][masterPort]，保存主节点信息
2、从节点中的定时任务发现主节点信息，建立和主节点的socket连接
3、从节点发送Ping信号，主节点返回Pong，两边能互相通信。
4、如果从节点中设置了masterauth选项，则从节点需要向主节点进行身份验证；没有设置该选项，则不需要验证。
5、连接建立后，主节点将所有数据发送给从节点（数据同步）
6、主节点把当前的数据同步给从节点后，便完成了复制的建立过程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

需要注意的是，slaveof是异步命令，从节点完成主节点ip和port的保存后，向发送slaveof命令的客户端直接返回OK，实际的复制操作在这之后才开始进行。

主从复制的作用主要包括：

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

• 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

• 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

面试官：那你能详细说下数据同步的过程吗？

（我心想：这也问的太细了吧）
我：可以。redis2.8之前使用sync[runId][offset]同步命令，redis2.8之后使用psync[runId][offset]命令。

两者不同在于，sync命令仅支持全量复制过程，psync支持全量和部分复制。

介绍同步之前，先介绍几个概念：

runId：每个redis节点启动都会生成唯一的uuid，每次redis重启后，runId都会发生变化。

offset：主节点和从节点分别维护一个复制偏移量（offset），代表的是主节点向从节点传递的字节数；主节点每次向从节点传播N个字节数据时，主节点的offset增加N；从节点每次收到主节点传来的N个字节数据时，从节点的offset增加N。

这样，主节点同时保存自己的offset和从节点的offset，通过对比offset来判断主从节点数据是否一致。

例如，如果主节点的offset是1000，而从节点的offset是500，那么部分复制就需要将offset为501-1000的数据传递给从节点。而offset为501-1000的数据存储的位置，就是下面要介绍的复制积压缓冲区。

repl_backlog_size：表示复制积压缓冲区的大小，是保存在主节点上的一个固定长度的先进先出队列，默认大小是1MB。当主节点开始有从节点时创建，其作用是备份主节点最近发送给从节点的数据

注意，无论主节点有一个还是多个从节点，都只需要一个复制积压缓冲区。

（1）主节点发送数据给从节点过程中，主节点还会进行一些写操作，这时候的数据存储在复制缓冲区中。从节点同步主节点数据完成后，主节点将缓冲区的数据继续发送给从节点，用于部分复制。
（2）主节点响应写命令时，不但会把命名发送给从节点，还会写入复制积压缓冲区，用于复制命令丢失的数据补救。

上面是psync的执行流程：

从节点发送psync[runId][offset]命令，主节点有三种响应：

（1）FULLRESYNC：第一次连接，进行全量复制
（2）CONTINUE：进行部分复制
（3）ERR：不支持psync命令，进行全量复制

面试官：很好，那你能具体说下全量复制和部分复制的过程吗？

我：可以

上面是全量复制的流程。主要有以下几步：

1、从节点发送psync ? -1命令（因为第一次发送，不知道主节点的runId，所以为?，因为是第一次复制，所以offset=-1）。
2、主节点发现从节点是第一次复制，返回FULLRESYNC {runId} {offset}，runId是主节点的runId，offset是主节点目前的offset。
3、从节点接收主节点信息后，保存到info中。
4、主节点在发送FULLRESYNC后，启动bgsave命令，生成RDB文件（数据持久化）。
5、主节点发送RDB文件给从节点。到从节点加载数据完成这段期间主节点的写命令放入缓冲区。
6、从节点清理自己的数据库数据。
7、从节点加载RDB文件，将数据保存到自己的数据库中。
8、如果从节点开启了AOF，从节点会异步重写AOF文件。

关于部分复制有以下几点说明：

1、部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施，使用psync[runId][offset]命令实现。

当从节点正在复制主节点时，如果出现网络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，主节点的复制积压缓冲区将这部分数据直接发送给从节点，这样就可以保持主从节点复制的一致性。补发的这部分数据一般远远小于全量数据。
2、主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内的复制积压缓冲区依然可以保存最近一段时间的写命令数据。
3、当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当做psync参数发送给主节点，要求进行部分复制。
4、主节点接收到psync命令后首先核对参数runId是否与自身一致，如果一致，说明之前复制的是当前主节点；

之后根据参数offset在复制积压缓冲区中查找，如果offset之后的数据存在，则对从节点发送+COUTINUE命令，表示可以进行部分复制。因为缓冲区大小固定，若发生缓冲溢出，则进行全量复制。
5、主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

• 哨兵

面试官：那主从复制会存在哪些问题呢？

我：主从复制会存在以下问题：

1、一旦主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
2、主节点的写能力受到单机的限制。
3、主节点的存储能力受到单机的限制。
4、原生复制的弊端在早期的版本中也会比较突出，比如：redis复制中断后，从节点会发起psync。此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的卡顿。

面试官：那比较主流的解决方案是什么呢？

我：当然是哨兵啊。

面试官：那么问题又来了。那你说下哨兵有哪些功能？

Redis Sentinel（哨兵）的架构图

我：Redis Sentinel（哨兵）主要功能包括主节点存活检测、主从运行情况检测、自动故障转移、主从切换。

Redis Sentinel最小配置是一主一从。Redis的Sentinel系统可以用来管理多个Redis服务器，该系统可以执行以下四个任务：

1、监控：不断检查主服务器和从服务器是否正常运行。
2、通知：当被监控的某个redis服务器出现问题，Sentinel通过API脚本向管理员或者其他应用程序发出通知。
3、自动故障转移：当主节点不能正常工作时，Sentinel会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点，这样人工干预就可以免了。
4、配置中心：在Redis Sentinel模式下，客户端应用在初始化时连接的是Sentinel节点集合，从中获取主节点的信息。

面试官：那你能说下哨兵的工作原理吗？

我：话不多说，直接上图：

1、每个Sentinel节点都需要定期执行以下任务：哨兵默认每隔十秒向节点发送info，获取主从服务器的信息，及时更新哨兵下的服务器实例；

每个Sentinel以每秒一次的频率，向它所知的主服务器、从服务器以及其他的Sentinel实例发送一个PING命令。（如上图）

2、如果一个实例距离最后一次有效回复PING命令的时间超过down-after-milliseconds所指定的值，那么这个实例会被Sentinel标记为主观下线。（如上图）

3、如果一个主服务器被标记为主观下线，那么正在监视这个服务器的所有Sentinel节点，要以每秒一次的频率确认主服务器的确进入了主观下线状态。

4、如果一个主服务器被标记为主观下线，并且有足够数量的Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线。

5、一般情况下，每个Sentinel会以每10秒一次的频率向它已知的所有主服务器和从服务器发送INFO命令，当一个主服务器被标记为客观下线时，Sentinel向下线主服务器的所有从服务器发送INFO命令的频率，会从10秒一次改为每秒一次。

6、Sentinel和其他Sentinel协商客观下线的主节点的状态，如果处于SDOWN状态，则投票自动选出新的主节点，将剩余从节点指向新的主节点进行数据复制。

7、当没有足够数量的Sentinel同意主服务器下线时，主服务器的客观下线状态就会被移除。当主服务器重新向Sentinel的PING命令返回有效回复时，主服务器的主观下线状态就会被移除。

注意：一个有效的 PING 回复可以是：+PONG、-LOADING 或者 -MASTERDOWN。如果 服务器 返回除以上三种回复之外的其他回复，又或者在 指定时间 内没有回复 PING 命令， 那么 Sentinel 认为服务器返回的回复 无效（non-valid）。

面试官：不错，面试前没少下工夫啊，今天Redis这关你过了，明天找个时间我们再聊聊其他的。（露出欣慰的微笑）

我：没问题。

• 总结

本文在一次面试的过程中讲述了Redis是什么，Redis的特点和功能，Redis缓存的使用，Redis为什么能这么快，Redis缓存的淘汰策略，持久化的两种方式，Redis高可用部分的主从复制和哨兵的基本原理。只要功夫深，铁杵磨成针，平时准备好，面试不用慌。虽然面试不一定是这样问的，但万变不离其“宗”。

（笔者觉得这种问答形式的博客很不错，可读性强而且读后记的比较深刻）

参考：

https://juejin.im/post/5dccf260f265da0bf66b626d#heading-8
https://www.cnblogs.com/hello-/articles/9599380.html
https://www.cnblogs.com/kismetv/p/9236731.html
https://juejin.im/post/5b7d226a6fb9a01a1e01ff64