Redis主从复制、读写分离

一.Redis的主从复制是什么

主机数据更新后根据配置和策略，自行同步到备机的master/slave机制，Master以写为主，Slave以读为主。

二.Redis的主从复制能干什么

　　读写分离

　　容灾备份

三.Redis主从复制的几个阶段

　　1.连接建立阶段

　　2.数据同步阶段：就是从节点的初始化过程，可以通过全量复制或者增量复制来进行操作。

　　3.命令传播阶段：数据同步阶段完成之后，主从节点进入命令传播阶段；在这个阶段主节点将自己的写操作发送给从节点，从节点接受并执行；从而保证主从节点数据的一致性。在命令传播阶段，除了发送写命令，主从节点之间还维护着心跳机制PING和REPLCONF ACK。

四.怎么用

1.配从不配主

2.从库配置：slaveof 主库ip 主库端口（如果当前服务器已经是某台主服务器的从属服务器，那么执行SLAVEOF host port 将使当前服务器停止对旧主服务器的同步，并清除旧的数据集，转而向新的主服务器进行同步）

　　每次从库和主库断开之后，都需要重新连接，除非配置进Redis.conf文件

　　使用info replication指令可以查看当前Redis实例的情况（包括是主库还是从库，如果是主库，有几个从库，从库监听的端口号.......）

3.常见的应用情况：
　　3.1当master关闭之后，那么这个master的所有slave将原地待命，当master重新启动之后，那么这些slave将自动连接上这个master

　　3.2当master的某个从库slave挂掉之后，并不影响主库master和其余从库slave的使用，但是当挂掉的这台重新启动之后，将不再是这台master的从库，而是恢复master身份。

　　3.3上一个slave可以是下一个slave的Master，slave同样可以接受其他slaves的连接和同步请求，那么该slave作为链条中下一个slave的master，可以有效减轻master的压力，但是这样就会出现延迟性，不能保证数据的一致性。

　　3.4当主服务挂掉之后，此时为了正常使用，在从库中抉择出一个服务器作为主服务器，首先执行SLAVEOF no one使得这个从属服务器关闭复制功能，并恢复自己主服务器的身份（原来同步所得数据集不会被丢弃），然后将另一台从属服务器和它建立主从关系。

四.【数据同步阶段】replication的原理：

• 　　全量复制：用于第一次复制或者其他无法进行部分复制的情况，将主库所有数据都发送给从库，这是一个非常重型的操作。
• 　　增量复制：用于网络中断后的等情况的复制，只将主库在中断期间执行的写操作发送给从库，比全量复制更加高效。需要注意的是，如果中断的时间过长，导致主库没有完全保存中断期间执行的写操作(见下面的关于复制积压缓冲区的解释)，则无法执行部分复制，只能进行全量复制。

　　4.1全量复制

　　　（1）从节点判断无法进行部分复制，向主节点发送全量复制的请求；或从节点发送部分复制的请求，但主节点判断无法进行部分复制，于是进行全量复制；

　　　（2）主节点收到全量复制的命令后，执行bgsave（BGSAVE 命令用于在后台异步将内存数据库中的数据保存进磁盘中，BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，父进程继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出），在后台生成RDB文件，并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令

　　　（3）主节点的bgsave执行完成后，将RDB文件发送给从节点；从节点首先清除自己的旧数据，然后载入接收的RDB文件，将数据库状态更新至主节点执行bgsave时的数据库状态。

　　　（4）主节点将前述复制缓冲区中的所有写命令发送给从节点，从节点执行这些写命令，将数据库状态更新至主节点的最新状态

　　  （5）如果从节点开启了AOF，则会触发bgrewriteaof的执行，从而保证AOF文件更新至主节点的最新状态。

　　4.2增量复制

由于全量复制在主节点数据量较大时效率太低，因此Redis2.8开始提供部分复制，用于处理网络中断时的数据同步。

部分复制的实现，依赖于三个重要的概念：

（1）复制偏移量

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

offset用于判断主从节点的数据库状态是否一致：如果二者offset相同，则一致；如果offset不同，则不一致，此时可以根据两个offset找出从节点缺少的那部分数据。例如，如果主节点的offset是1000，而从节点的offset是500，那么部分复制就需要将offset为501-1000的数据传递给从节点。而offset为501-1000的数据存储的位置，就是下面要介绍的复制积压缓冲区。

（2）复制积压缓冲区

复制积压缓冲区是由主节点维护的、固定长度的、先进先出(FIFO)队列，默认大小1MB；当主节点开始有从节点时创建，其作用是备份主节点最近发送给从节点的数据（或者说是备份主节点最近的写操作）。注意，无论主节点有一个还是多个从节点，都只需要一个复制积压缓冲区。

在命令传播阶段，主节点除了将写命令发送给从节点，还会发送一份给复制积压缓冲区，作为写命令的备份；除了存储写命令，复制积压缓冲区中还存储了其中的每个字节对应的复制偏移量（offset）。由于复制积压缓冲区定长且是先进先出，所以它保存的是主节点最近执行的写命令；时间较早的写命令会被挤出缓冲区。

由于该缓冲区长度固定且有限，因此可以备份的写命令也有限，当主从节点offset的差距过大超过缓冲区长度时（当从节点中断时间太长的时候，复制积压缓冲区无法存储这段时间的全部的写操作，所以从节点只能选择增量复制），将无法执行部分复制，只能执行全量复制。反过来说，为了提高网络中断时部分复制执行的概率，可以根据需要增大复制积压缓冲区的大小(通过配置repl-backlog-size)；例如如果网络中断的平均时间是60s，而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为100KB，则复制积压缓冲区的平均需求为6MB，保险起见，可以设置为12MB，来保证绝大多数断线情况都可以使用部分复制。

从节点将offset发送给主节点后，主节点根据offset和缓冲区大小决定能否执行部分复制：

• 如果offset偏移量之后的数据，仍然都在复制积压缓冲区里，则执行部分复制；
• 如果offset偏移量之后的数据已不在复制积压缓冲区中（数据已被挤出），则执行全量复制。

（3）服务器运行ID(runid)

每个Redis节点(无论主从)，在启动时都会自动生成一个随机ID(每次启动都不一样)，由40个随机的十六进制字符组成；runid用来唯一识别一个Redis节点。通过info Server命令，可以查看节点的runid：

主从节点初次复制时，主节点将自己的runid发送给从节点，从节点将这个runid保存起来；当断线重连时，从节点会将这个runid发送给主节点；主节点根据runid判断能否进行部分复制：

• 如果从节点保存的runid与主节点现在的runid相同，说明主从节点之前同步过，主节点会继续尝试使用部分复制(到底能不能部分复制还要看offset和复制积压缓冲区的情况)；
• 如果从节点保存的runid与主节点现在的runid不同，说明从节点在断线前同步的Redis节点并不是当前的主节点，只能进行全量复制。

具体的细节请看下面这篇博文：https://www.cnblogs.com/kismetv/p/9236731.html（大佬就是大佬，整理的是真的详细）