redis之主从复制

redis 之 主从复制

当单个redis服务器如遇到断电情况，可以从持久化的备份中恢复数据，但是如果遇到系统崩溃，磁盘损坏等情况，这样就会使数据丢失。为了解决这种问题的发生，redis推出了主从复制。
主从复制可以进一步实现数据的读写分离，而对于只读项目，可以横向增加从服务器来分担主服务的压力。

主从复制的实现

首先准备三台redis 服务器，一台主服务器，两台从服务器。
####需要修改的配置

• slaveof ip地址 端口号 #指定本台从redis服务器的主服务器，在从服务器上必须配置这个配置，主服务器不用配置

slaveof 192.168.32.3 6379  //这是我设置的一台从服务上的配置

• 可选的配置

requirepass  设置密码，这是主服务器设置的  
 masterauth  主服务器密码    这个是在从服务器上配置的，如果注服务器没有设置密码，则不需要设置这个配置

主从复制原理

PSYNC命令具有完整重同步（full resynchronization）和部分重同步（partial resynchronization）两种模式：

完整重同步：

1、主服务器需要执行BGSAVE命令来生成RDB文件，这个生成操作会耗费主服务器大量的CPU、内存和磁盘I/O资源；
2、主服务器需要将自己生成的RDB文件发送给从服务器，这个发送操作会耗费主从服务器大量的网络资源（带宽和流量），
并对主服务器响应命令请求的时间产生影响；
3、接收到RDB文件的从服务器需要载入主服务器发来的RDB文件，并且在载入期间，
从服务器会因为阻塞而没办法处理命令请求。

部分重同步：

部分重同步用于处理断线后重复制情况：
当从服务器在断线后重新连接主服务器时，如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这些写命令，就可以将数据库更新至主服务器当前所处的状态。

部分重同步功能由以下三个部分构成：
主服务器的复制偏移量（replication offset）和从服务器的复制偏移量；
主服务器的复制积压缓冲区（replication backlog）；
服务器的运行ID（run ID）。

复制偏移量

执行复制的双方——主服务器和从服务器会分别维护一个复制偏移量：
主服务器每次向从服务器传播N个字节的数据时，就将自己的复制偏移量的值加上N；
从服务器每次收到主服务器传播来的N个字节的数据时，就将自己的复制偏移量的值加上N；

通过对比主从服务器的复制偏移量，程序可以很容易地知道主从服务器是否处于一致状态：
如果主从服务器处于一致状态，那么主从服务器两者的偏移量总是相同的；
相反，如果主从服务器两者的偏移量并不相同，那么说明主从服务器并未处于一致状态。

假设从服务器A在断线之后就立即重新连接主服务器，并且成功，那么接下来，从服务器将向主服务器发送PSYNC命令，报告从服务器A当前的复制偏移量为10086，那么这时，主服务器应该对从服务器执行完整重同步还是部分重同步呢？
如果执行部分重同步的话，主服务器又如何补偿从服务器A在断线期间丢失的那部分数据呢？
以上问题的答案都和复制积压缓冲区有关。

复制积压缓冲区

复制积压缓冲区是由主服务器维护的一个固定长度（fixed-size）先进先出（FIFO）队列，默认大小为1MB。
和普通先进先出队列随着元素的增加和减少而动态调整长度不同，固定长度先进先出队列的长度是固定的，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列。当主服务器进行命令传播时，它不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区里面，如图所示。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WCMaE6fo-1593350393518)(https://imgblog.csdnimg.cn/20200628211947459.png)]

因此，主服务器的复制积压缓冲区里面会保存着一部分最近传播的写命令，
并且复制积压缓冲区会为队列中的每个字节记录相应的复制偏移量，就像下表所示的那样。

当从服务器重新连上主服务器时，从服务器会通过PSYNC命令将自己的复制偏移量offset发送给主服务器，
主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作：
如果offset偏移量之后的数据（也即是偏移量offset+1开始的数据）仍然存在于复制积压缓冲区里面，
那么主服务器将对从服务器执行部分重同步操作；
相反，如果offset偏移量之后的数据已经不存在于复制积压缓冲区，那么主服务器将对从服务器执行完整重同步操作。

根据需要调整复制积压缓冲区的大小

Redis为复制积压缓冲区设置的默认大小为1MB，如果主服务器需要执行大量写命令，
又或者主从服务器断线后重连接所需的时间比较长，那么这个大小也许并不合适。

如果复制积压缓冲区的大小设置得不恰当，那么PSYNC命令的复制重同步模式就不能正常发挥作用，
因此，正确估算和设置复制积压缓冲区的大小非常重要。

复制积压缓冲区的最小大小可以根据公式second*write_size_per_second来估算：
其中second为从服务器断线后重新连接上主服务器所需的平均时间（以秒计算）；
而write_size_per_second则是主服务器平均每秒产生的写命令数据量（协议格式的写命令的长度总和）；

例如，如果主服务器平均每秒产生1 MB的写数据，而从服务器断线之后平均要5秒才能重新连接上主服务器，
那么复制积压缓冲区的大小就不能低于5MB。

为了安全起见，可以将复制积压缓冲区的大小设为2secondwrite_size_per_second，
这样可以保证绝大部分断线情况都能用部分重同步来处理。

至于复制积压缓冲区大小的修改方法，修改配置文件中repl-backlog-size的参数。

服务器运行ID

除了复制偏移量和复制积压缓冲区之外，实现部分重同步还需要用到服务器运行ID（run ID）：
每个Redis服务器，不论主服务器还是从服务，都会有自己的运行ID；
运行ID在服务器启动时自动生成，由40个随机的十六进制字符组成，
例如：53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3；

当从服务器对主服务器进行初次复制时，主服务器会将自己的运行ID传送给从服务器，
而从服务器则会将这个运行ID保存起来（注意哦，是从服务器保存了主服务器的ID）。

当从服务器断线并重新连上一个主服务器时，从服务器将向当前连接的主服务器发送之前保存的运行ID：
如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同，
那么说明从服务器断线之前复制的就是当前连接的这个主服务器，主服务器可以继续尝试执行部分重同步操作；

相反地，如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同，
那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器，
主服务器将对从服务器执行完整重同步操作。