Redis的主从同步

redis主从原理

一、复制过程

1、从节点执行 slaveof 命令

2、从节点只是保存了 slaveof 命令中主节点的信息，并没有立即发起复制

3、从节点内部的定时任务发现有主节点的信息，开始使用 socket 连接主节点

4、连接建立成功后，发送 ping 命令，希望得到 pong 命令响应，否则会进行重连

5、如果主节点设置了权限，那么就需要进行权限验证；如果验证失败，复制终止。

6、权限验证通过后，进行数据同步，这是耗时最长的操作，主节点将把所有的数据全部发送给从节点。

7、当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

二、数据间的同步

redis 同步有 2 个命令：
sync 和 psync，前者是 redis 2.8 之前的同步命令，后者是 redis 2.8 为了优化 sync 新设计的命令。我们会重点关注 2.8 的 psync 命令。

psync 命令需要 3 个组件支持：

a、主从节点各自复制偏移量

b、主节点复制积压缓冲区

c、主节点运行 ID

主从节点各自复制偏移量：

1、参与复制的主从节点都会维护自身的复制偏移量。

2、主节点在处理完写入命令后，会把命令的字节长度做累加记录，统计信息在 info replication 中的 masterreploffset 指标中。

3、从节点每秒钟上报自身的的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量。

4、从节点在接收到主节点发送的命令后，也会累加自身的偏移量，统计信息在 info replication 中。

5、通过对比主从节点的复制偏移量，可以判断主从节点数据是否一致。

主节点复制积压缓冲区：

1、复制积压缓冲区是一个保存在主节点的一个固定长度的先进先出的队列。默认大小 1MB。

2、这个队列在 slave 连接时创建。这时主节点响应写命令时，不但会把命令发送给从节点，也会写入复制缓冲区。

3、他的作用就是用于部分复制和复制命令丢失的数据补救。通过 info replication 可以看到相关信息。

主节点运行 ID：

1、每个 redis 启动的时候，都会生成一个 40 位的运行 ID。

2、运行 ID 的主要作用是用来识别 Redis 节点。如果使用 ip+port 的方式，那么如果主节点重启修改了 RDB/AOF 数据，从节点再基于偏移量进行复制将是不安全的。所以，当运行 id 变化后，从节点将进行全量复制。也就是说，redis 重启后，默认从节点会进行全量复制。

如果在重启时不改变运行 ID 呢？

可以通过 debug reload 命令重新加载 RDB 并保持运行 ID 不变。从而有效的避免不必要的全量复制。

2、他的缺点则是：debug reload 命令会阻塞当前 Redis 节点主线程，因此对于大数据量的主节点或者无法容忍阻塞的节点，需要谨慎使用。一般通过故障转移机制可以解决这个问题。

psync 命令的使用方式：

命令格式为 psync{runId}{offset}

runId：从节点所复制主节点的运行

id offset：当前从节点已复制的数据偏移量

主节点会根据 runid 和 offset 决定返回结果：

1、如果回复 +FULLRESYNC {runId} {offset} ，那么从节点将触发全量复制流程。

2、如果回复 +CONTINUE，从节点将触发部分复制。

3、如果回复 +ERR，说明主节点不支持 2.8 的 psync 命令，将使用 sync 执行全量复制。

4、到这里，数据之间的同步就讲的差不多了，篇幅还是比较长的。主要是针对 psync 命令相关之间的介绍。

三、全量复制

1、全量复制是 Redis 最早支持的复制方式，也是主从第一次建立复制时必须经历的的阶段。

2、触发全量复制的命令是 sync 和 psync。

3、之前说过，这两个命令的分水岭版本是 2.8，redis 2.8 之前使用 sync 只能执行全量不同，2.8 之后同时支持全量同步和部分同步。

四、部分复制

1、当从节点正在复制主节点时，如果出现网络闪断和其他异常，从节点会让主节点补发丢失的命令数据

2、主节点只需要将复制缓冲区的数据发送到从节点就能够保证数据的一致性，相比较全量复制，成本小很多。

a、当从节点出现网络中断，超过了 repl-timeout 时间，主节点就会中断复制连接。
b、主节点会将请求的数据写入到“复制积压缓冲区”，默认 1MB。

c、当从节点恢复，重新连接上主节点，从节点会将 offset 和主节点 id 发送到主节点

d、主节点校验后，如果偏移量的数后的数据在缓冲区中，就发送 cuntinue 响应 —— 表示可以进行部分复制

e、主节点将缓冲区的数据发送到从节点，保证主从复制进行正常状态。

五、心跳

主从节点在建立复制后，他们之间维护着长连接并彼此发送心跳命令。

心跳的关键机制如下：

1、主从都有心跳检测机制，各自模拟成对方的客户端进行通信，通过 client list 命令查看复制相关客户端信息，主节点的连接状态为 flags = M，从节点的连接状态是 flags = S。

2、主节点默认每隔 10 秒对从节点发送 ping 命令，可修改配置 repl-ping-slave-period 控制发送频率。

3、从节点在主线程每隔一秒发送 replconf ack{offset} 命令，给主节点上报自身当前的复制偏移量。

4、主节点收到 replconf 信息后，判断从节点超时时间，如果超过 repl-timeout 60 秒，则判断节点下线。
注意：为了降低主从延迟，一般把 redis 主从节点部署在相同的机房/同城机房，避免网络延迟带来的网络分区造成的心跳中断等情况。

六、总结

Redis主从同步策略

1、主从刚刚连接的时候，进行全量同步；

2、全同步结束后，进行增量同步。

3、如果有需要，slave 在任何时候都可以发起全量同步。

4、redis 策略是，无论如何，首先会尝试进行增量同步；

5、不成功，要求从机进行全量同步。

注意点：

1、如果多个Slave断线了，需要重启的时候，因为只要Slave启动，就会发送sync请求和主机全量同步，

2、当多个同时出现的时候，可能会导致Master IO剧增宕机。

主从复制的特点

采用异步复制；
一个主redis可以含有多个从redis；
每个从redis可以接收来自其他从redis服务器的连接；
主从复制对于主redis服务器来说是非阻塞的，这意味着当从服务器在进行主从复制同步过程中，主redis仍然可以处理外界的访问请求；
主从复制对于从redis服务器来说也是非阻塞的，这意味着，即使从redis在进行主从复制过程中也可以接受外界的查询请求，只不过这时候从redis返回的是以前老的数据，
如果你不想这样，那么在启动redis时，可以在配置文件中进行设置，那么从redis在复制同步过程中来自外界的查询请求都会返回错误给客户端；（虽然说主从复制过程中
对于从redis是非阻塞的，但是当从redis从主redis同步过来最新的数据后还需要将新数据加载到内存中，在加载到内存的过程中是阻塞的，在这段时间内的请求将会被阻，
但是即使对于大数据集，加载到内存的时间也是比较多的）；
主从复制提高了redis服务的扩展性，避免单个redis服务器的读写访问压力过大的问题，同时也可以给为数据备份及冗余提供一种解决方案；
为了编码主redis服务器写磁盘压力带来的开销，可以配置让主redis不在将数据持久化到磁盘，而是通过连接让一个配置的从redis服务器及时的将相关数据持久化到磁盘，
不过这样会存在一个问题，就是主redis服务器一旦重启，因为主redis服务器数据为空，这时候通过主从同步可能导致从redis服务器上的数据也被清空；

主从同步时的几个问题

1. 在上面的全量同步过程中，master会将数据保存在rdb文件中然后发送给slave服务器，但是如果master上的磁盘空间有效怎么办呢？那么此时全部同步对于master来说
将是一份十分有压力的操作了。此时可以通过无盘复制来达到目的，由master直接开启一个socket将rdb文件发送给slave服务器。（无盘复制一般应用在磁盘空间有限但是网
络状态良好的情况下）
 
2. 主从复制结构，一般slave服务器不能进行写操作，但是这不是死的，之所以这样是为了更容易的保证主和各个从之间数据的一致性，如果slave服务器上数据进行了修改，
那么要保证所有主从服务器都能一致，可能在结构上和处理逻辑上更为负责。不过你也可以通过配置文件让从服务器支持写操作。（不过所带来的影响还得自己承担哦。。。）
 
3. 主从服务器之间会定期进行通话，但是如果master上设置了密码，那么如果不给slave设置密码就会导致slave不能跟master进行任何操作，所以如果你的master服务器
上有密码，那么也给slave相应的设置一下密码吧（通过设置配置文件中的masterauth）;
 
4. 关于slave服务器上过期键的处理，由master服务器负责键的过期删除处理，然后将相关删除命令已数据同步的方式同步给slave服务器，slave服务器根据删除命令删除
本地的key。

当主服务器不能持久化时复制的安全性

在进行主从复制设置时，强烈建议在主服务器上开启持久化，当不能这么做时，比如考虑到延迟的问题，应该将实例配置为避免自动重启。
 
为什么不持久化的主服务器自动重启非常危险呢？
为了更好的理解这个问题，看下面这个失败的例子，其中主服务器和从服务器中数据库都被删除了。
 
设置节点A为主服务器，关闭持久化，节点B和C从节点A复制数据。
这时出现了一个崩溃，但Redis具有自动重启系统，重启了进程，因为关闭了持久化，节点重启后只有一个空的数据集。
节点B和C从节点A进行复制，现在节点A是空的，所以节点B和C上的复制数据也会被删除。
当在高可用系统中使用Redis Sentinel，关闭了主服务器的持久化，并且允许自动重启，这种情况是很危险的。
比如主服务器可能在很短的时间就完成了重启，以至于Sentinel都无法检测到这次失败，那么上面说的这种失败的情况就发生了。
 
如果数据比较重要，并且在使用主从复制时关闭了主服务器持久化功能的场景中，都应该禁止实例自动重启。

只读服务器

从Redis 2.6开始，从服务器支持只读模式，并且是默认模式。这个行为是由Redis.conf文件中的slave-read-only 参数控制的，
可以在运行中通过CONFIG SET来启用或者禁用。
 
只读的从服务器会拒绝所有写命令，所以对从服务器不会有误写操作。但这不表示可以把从服务器实例暴露在危险的网络环境下，
因为像DEBUG或者CONFIG这样的管理命令还是可以运行的。不过你可以通过使用rename-command命令来为这些命令改名来增加安全性。
 
你可能想知道为什么只读限制还可以被还原，使得从服务器还可以进行写操作。虽然当主从服务器进行重新同步或者从服务器重启后，
这些写操作都会失效，还是有一些使用场景会想从服务器中写入临时数据的，但将来这个特性可能会被去掉。

限制有N个以上服务器才允许写入

从Redis 2.8版本开始，可以配置主服务器连接N个以上从服务器才允许对主服务器进行写操作。但是，因为Redis使用的是异步主从复制，
没办法确保从服务器确实收到了要写入的数据，所以还是有一定的数据丢失的可能性。
 
这一特性的工作原理如下：
1. 从服务器每秒钟ping一次主服务器，确认处理的复制流数量。
2. 主服务器记住每个从服务器最近一次ping的时间。
3. 用户可以配置最少要有N个服务器有小于M秒的确认延迟。
4. 如果有N个以上从服务器，并且确认延迟小于M秒，主服务器接受写操作。
 
还可以把这看做是CAP原则（一致性，可用性，分区容错性）不严格的一致性实现，虽然不能百分百确保一致性，但至少保证了丢失的数据不会超过M秒内的数据量。
 
如果条件不满足，主服务器会拒绝写操作并返回一个错误。
1. min-slaves-to-write（最小从服务器数）
2. min-slaves-max-lag（从服务器最大确认延迟）
3. 主服务器记住每个从服务器最近一次ping的时间。
4. 用户可以配置最少要有N个服务器有小于M秒的确认延迟。
5. 如果有N个以上从服务器，并且确认延迟小于M秒，主服务器接受写操作。
 
还可以把这看做是CAP原则（一致性，可用性，分区容错性）不严格的一致性实现，虽然不能百分百确保一致性，但至少保证了丢失的数据不会超过M秒内的数据量。
 
如果条件不满足，主服务器会拒绝写操作并返回一个错误。
1.min-slaves-to-write（最小从服务器数）
2.min-slaves-max-lag（从服务器最大确认延迟）