redis 主从复制

1、主从复制

至少由2个redis实例构成，一个主节点，其余的都是从节点，一般情况下都是进行读写分离，主节点负责处理写请求，从节点负责处理读请求，主节点上的数据会不停地发生改变，同时也不停地将这种改变复制给其它的从节点，让从节点上的数据与主节点上的数据保持一致性。 另外，从节点还可以有从节点。

主从复制的优点：将读请求分流到从节点，减轻主节点压力，让主节点专注于写请求，提升了写性能；从节点可以有多个，大大提升了读性能；另外，还可以起到数据备份的功能，如果主节点挂了，从节点上还保存着数据。

主从复制的缺点：同样的数据分别存放在多个地方，容易发生数据不一致问题；从节点上的数据多少会有点延时，即不是特别的实时；不支持高可靠性和可用性，因为主节点一旦挂了，redis 就不提供写服务了。

注意：从节点的数量增加有利于提升整体读性能，但是也不是越多越好，从节点太多，会增加主节点在数据同步工作的压力，于是可以只给主节点配置一个从节点 B，再给这个从节点 B 配置多个从节点，这样的话，主节点就只需给 B 节点做同步工作，然后 B 节点负责同步给其它从节点。 这样做的优点是减轻主节点的压力，缺点是数据的一致性会减弱（一层一层地同步，使得数据不够实时）。

2、主从复制的工作原理

在配置好整个主从体系之后，启动它们，从节点会向主节点发送 sync 命令，主节点收到后，创建一个线程出来，这个线程专门用于生成主节点里面数据的 RDB 快照文件，在此期间，如果有新的写请求到来，执行新的写请求并且主节点会将这些写命令缓存起来，等 RDB 文件生成后，将 RDB 文件发送给从节点，从节点收到 RDB 文件后，根据文件内容进行一次数据同步（全量同步），等从节点完成后全量同步后，向主节点返回OK，这时候就开始了增量同步，即主节点就会开始将缓存起来的写命令发送给从节点，并且后面主节点收到的所有写命令都会发送给从节点，从节点将这些写命令在自己身上执行一遍达到数据同步。

主节点什么时候会发送写命令给从节点呢？2种策略：第一种，一旦有写命令出现，就立即发送给从节点，这样数据实时性更高，一致性更强，延迟低，但是主节点的压力会增大；第二种，写命令会暂时攒着，等攒到一定大小的时候，才发给从节点，如果写命令比较少，一直攒不够，还有另一个时间限制，一旦超过这个时间，不管写命令有多少，也要发送给从节点，延迟高一点，但是压力小一点，不用那么频繁去网络通信。

如果从节点与主节点因为网络原因断开了连接，从节点会尝试重连的，一旦连接上之后，会向主节点发送 psync 命令，命令中附有主节点ID 和 偏移量，主节点收到后，查看ID是否是自己的，如果不是，则说明是新的从节点加入了，就需要进行全量同步； 如果是，表明这个节点是我的从节点，然后去复制积压缓冲队列中检查是否该偏移量的写命令还在队列中，如果在，则从该偏移量开始的所有写命令都发送给从节点，否则，就只能重新进行全量同步了。

什么是偏移量？什么是复制积压缓冲队列？在主从复制的命令传播阶段（传输写命令的阶段），主节点将每一个传输给从节点的写命令都赋予了一个偏移量，并且发送给从节点后，还要将写命令缓存在一个队列（复制积压缓冲队列）中，队列大小默认1M，写命令是先进先出。

3、主从的心跳

主节点每隔 10 秒（默认）去 ping 一次从节点，查看从节点是否还或者，从节点每隔 1 秒（默认）去发送一个心跳消息给主节点，消息里有偏移量，主节点可以知道从节点还是正常的，另外将偏移量和主节点的偏移量比较，如果不一样，说明从节点数据不够一致，立即将从节点的偏移量之后的数据发送给从节点。