redis（三）主从复制概述，原理，常见问题

问题思考：当Redis服务器发生单点故障硬盘损坏时，无论是RDB还是AOF机制都无法恢复数据。如何实现高可用性？

（一）主从复制概述

主从复制：是指将一台Redis服务器的数据，复制到其他Redis服务器上。前者称为主服务器，后者称为从服务器；数据的复制是单向的，只能由主服务器到从服务器。

默认情况下，每台Redis都是主服务器；且一个主服务器可以有多个从服务器（或者没有从服务器）；但是一个从服务器只能有一个主服务器。

作用：

（1） 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
（2）故障恢复：当主服务器出现问题，由从服务器提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
（3）负载均衡：在主从复制的基础上配合读写分离，可以由主服务器提供写服务，由从服务器提供读的服务（即写Redis数据时应用连接主服务器，读Redis数据时应用连接从服务器），分担服务器的负载；尤其写少读多的场景下，通过多个从服务器分担读负载，可以提高Redis服务器的并发量。
（4）高可用基石：主从复制也是哨兵和集群能够实施的基础，一次主从复制是Redis的高可用基石。

（二）主从复制原理

主从复制开启和关闭：

从服务器开启主从复制有三种方式：
（1）配置文件，在从服务器的Reids.conf中加入：
slaveof
（2）启动命令，Redis-Server启动命令后输入：–
slaveof
（3）客户端命令，客户端执行slaveof,则该Redis服务器成为从服务器。

关闭服务：

在从服务器输入：slaveof no one

主从复制三个阶段：

1：连接准备：主从服务器之间建立连接，为数据同步做好准备。
2：数据同步：从服务器向主服务器发送psync命令开始同步，可以分为全量复制和部分复制。
3：命令传播：主服务器将自己执行的写命令发送给从服务器，从服务器接收命令并执行，从而保证从服务器数据的一致性。

1：连接准备

（1）：从服务器保存主服务器的host和ip信息，异步发送slaveof命令给主服务器 直接返回OK，复制开始进行。
（2）：主服务会建立Socket连接，用于RDB文件，同步命令传播。从服务器作为主服务器的client。
（3）：从服务器发送ping命令检查socket是否可用以及主服务是否能正常处理请求。从服务器可能接受到三种相应，pone,超时,非pone 结果。
（4）：身份验证，如果从服务器的配置文件中设置了masterauth，主从服务器的密码必须相同才能通过验证。
（5）：从服务器发送自身的host与ip信息给主服务器。

2：数据同步

全量复制：

（1）：从服务器向主服务器发送psync命令
（2）：主服务器收到全量复制的命令后，执行bgsave。在后台生成RDB文件 ，并使用复制缓存区记录从现在开始执行的所有写命令
（3）：主服务器的bgsave执行完成后，将RDB文件发送给从服务器。在从服务器清除自己的旧数据，然后载入接收的RDB文件，将数据库状态更新至主服务器执行bgsave时的数据库状态。
（4）：主服务器将复制缓存区中的所有写命令发送给从服务器，从服务器执行这些写命令，使主从服务器的数据库数据保持一致性。

RDB文件从创建到传输完毕消耗的总时间超过repl-timeout所配置的值（默认60秒），从节点将放弃接受RDB文件并清理已经下载的临时文件，导致全量复制失败,数据量较大的节点容易出现主从数据同步超时，需要响应的调整repl-timeout的值。

Redis支持无盘复制，生成的RDB文件不保存到硬盘而是直接通过网络发送给从节点，通过repldiskless-sync参数控制，默认关闭。

client buffer是在server端实现的一个读取缓冲区。redis server在接收到客户端的请求后，把响应结果写入到client buffer中，而不是直接发送给客户端。

client-output-buffer-limit slave 256MB 64MB 60，表示从库的复制客户端如果60秒内缓冲区消耗持续大于64MB或者直接超过256MB时，主节点将直接关闭复制客户端连接。

如果主节点创建和传输RDB的时间过长，对于高流量写入场景非常容易造成主节点复制客户端缓冲区溢出。

全量复制的缺点：

（1）：主服务器通过bgsave命令fork子进程进行RDB持久化的时候，该过程是非常消耗CPU，内存（页表复制），硬盘IO资源。
（2）：主服务器通过网络将RDB文件发送给从服务器，对主从服务器的带宽带来很大的消耗。
（3）：从服务器清空老数据，载入新的RDB文件的过程是阻塞的，无法响应客户端命令。

部分复制：

结构组成：

（1）：主服务器的复制偏移量。

（2）：主服务器的复制积压缓冲区。


（3）：服务器的运行（Run ID）

部分复制原理：

（1）当主从节点之间网络出现中断时，如果超过repl-timeout时间，主节点会认为从节点故障并中断复制连接。
（2）主从连接中断期间主节点依然响应命令并且保存在主节点的复制积压缓冲区中，但因复制连接中断命令无法发送给从节点。
（3） 当主从节点网络恢复后，从节点会再次连上主节点。
（4） 当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当作psync参数发送给主节点，要求进行部分复制操作。
（5） 主节点接到psync命令后首先核对参数runId是否与自身一致，如果一致，说明之前复制的是当前主节点；之后根据参数offset在自身复制积压缓冲区查找，如果偏移量之后的数据存在缓冲区中，则对从节点发送+CONTINUE响应，表示可以进行部分复制。
（6）主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。

3：命令传播

在命令传播阶段，除了发送写命令，主从服务器还维持着心跳机制：PING和REPLCONG ACK。

1：主服务器向从服务器发送PING命令
每个指定的时间，主服务器会向从服务器发送PING命令，这个PING命令的作用，主要是为了让从服务器进行超时判断，PING发送的频率由repl-ping-slave-period参数控制，单位为秒，默认是10s.
2:从服务器向主服务器发送REPLCONF ACK命令
在命令传播阶段，从节点会向主节点发送REPLCONF ACK，频率是每秒1次；命令是REPLCONF ACK{offset}，其中offset指的是从节点保存的复制偏移量。

REPLCONF ACK作用包括：

实时监测主从服务器网络状态：该命令会被主服务器用于复制超时的判断。主服务器上使用info replaction可以看到从服务器的状态中的lag值，表示距离上次收到命令的间间隔，正常情况为0或者1。
监测命令丢失：从服务器发送自身的offset,主服务器会与自己的offset对比。如果从服务器数据缺失（如网络丢包），主服务通过复制积压缓冲区推送缺失的数据，offset和复制积压缓冲区，不仅可以用于部分复制，也可以用于处理命令丢失等情形；区别在于前者是在断线重连后进行的，后者是在主从节点没有断线的情况下进行的。
辅助保证从服务器的数量和延迟：Redis主服务器中使用min-slaves-to-write和min-slaves-max-lag
参数，来保证所有从服务器的延迟都大于min-slaves-max-lag，则主节点拒绝执行写命令。

4：常见问题

（1）数据不一致的问题
（2）数据过期问题
（3）故障切换问题
（4）复制超时问题
（5）输出缓冲区溢出问题

不同场景的优化方案：

主从同步配置：