redis-主从复制

 

引言

我们都知道redis性能很高，单机版的qps可以达到10万+，但是即使如此我们也不会在生产环境去搭建单机版本的redis，原因如下：

1、因为存在单点，如果进程挂掉或者机器宕机，redis不可用

2、redis的读和写全在一台机器上，无法满足读多写少的场景。

主从流程架构

Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，Redis的主从结构可以采用一主多从或者级联结构，下图为级联结构。

1.搭建主从架构

接下来教大家如何搭建主从架构的redis，我们可以根据不同的端口号模拟在单机启动3个redis进程，端口号6379的为master，端口号6370 和6371的为slave。

我们首先复制redis.conf文件2份，分别为redis_6370.conf 和redis_6371.conf ,然后分别对这两个文件修改如下参数：

1slaveof 127.0.0.1 6379

启动master：

1./redis-server redis.conf

启动slave1：

1./redis-server redis_6370.conf

启动slave2：

1./redis-server redis_6371.conf

接下来我们在master上设置一个值，如下图：

我们看下slave1 和slave2 上是否能取到该值，如下图：

 

可以看到此时slave1和slave2已经有相应的值，说明同步完成。

2. Redis各配置参数介绍:

  1. slaveof
  2. 设置从节点指向要复制的主节点
  3. masterauth
  4. 复制使用的密码
  5. slave-serve-stale-data yes
  6. 当slave丢失与master的连接时，或者slave仍然在于master进行数据同步时（还没有与master保持一致）
  7. slave可以有两种方式来响应客户端请求：
  8. 1) 如果 slave-serve-stale-data 设置成 'yes' (the default) slave会仍然响应客户端请求,此时可能会有问题。
  9. 2) 如果 slave-serve-stale data设置成 'no' slave会返回"SYNC with master in progress"这样的错误信息。 但 INFO 和SLAVEOF命令除外。
  10. slave-read-only yes
  11. 从节点是否只读。
  12. repl-diskless-sync no （no, Disk-backed, Diskless ）
  13. 复制集同步策略：磁盘或者socket
  14. no： 表示不启用
  15. Disk-backed, 基于磁盘的
  16. Diskless： 无磁盘的
  17. 新slave连接或者老slave重新连接时候不能只接收不同，得做一个全同步。需要一个新的RDB文件dump出来，然后从master传到slave。
  18. 可以有两种情况：
  19. 1、基于硬盘（disk-backed）：master创建一个新进程dump RDB，完事之后由父进程（即主进程）增量传给slaves。
  20. 2、基于socket（diskless）：master创建一个新进程直接dump RDB到slave的socket，不经过主进程，不经过硬盘。
  21. 基于硬盘的话，RDB文件创建后，一旦创建完毕，可以同时服务更多的slave就是一对多。基于socket的话， 新slave来了后，得排队（如果超出了repl-diskless-sync-delay还没来），完事儿一个再进行下一个。
  22. 当用diskless的时候，master等待一个repl-diskless-sync-delay的秒数，如果没slave来的话，就直接传，后来的得排队等了。否则就可以一起传。
  23. disk较慢，并且网络较快的时候，可以用diskless。（默认用disk-based）
  24. repl-diskless-sync-delay 5
  25. 如果启用无磁盘的同步，在接入进来延迟5秒以后在同步数据
  26. repl-ping-slave-period 10
  27. 主节点每隔10秒探测一次从节点是否存活。
  28. repl-timeout 60
  29. 主从节点如果网络断开超时60秒未通信，就超时断开连接
  30. repl-disable-tcp-nodelay no
  31. 是否启用tcp的延迟发送， 就是说数据量比TCP的首部信息加起来还要小，这样反复的发送较小的数据很占用资源，当开启以后就会累积到一定的数据量在发送。但是对于较高的场景，如果延迟发送的时间过长，可能主持同步时间就会延迟。
  32. repl-backlog-size 1mb
  33. 如果主Redis等了一段时间之后，还是无法连接到从Redis，那么缓冲队列中的数据将被清理掉。我们可以设置主Redis要等待的时间长度。如果设置为0，则表示永远不清理。默认是1个小时。
  34. slave-priority 100
  35. 复制集群中，主节点故障时，sentinel应用场景中的主节点选举时使用的优先级；数字越小优先级越高，但0表示不参与选举；
  36. min-slaves-to-write 3
  37. 主节点仅允许其能够通信的从节点数量大于等于此处的值时接受写操作；意思就是说，我们的redis集群最少要有3台以上才能满足我们线上的业务，如果低于这个数，将无法启用.
  38. min-slaves-max-lag 10
  39. 从节点延迟时长滞后超出此处指定的时长时，主节点会拒绝写入操作；

 

 

主从底层实现原理

redis的复制功能主要分为同步(sync)和命令传播（command propagate）两个操作：

  1. 同步操作用于将从服务器的数据库状态更新至主服务器当前所处的数据库状态；
  2. 命令传播操作则用于在主服务器的数据库状态被修改，导致主从服务器的数据库状态出现不一致时，让主从服务器的数据库重新回到一致状态。

以下为redis2.8之前版本的同步实现原理:

1. 同步

当客户端向从服务器发送SLAVEOF命令，要求从服务器复制主服务器时，从服务器首先需要执行同步操作，也即是，将从服务器的数据库状态更新至主服务器当前所处的数据库状态。

从服务器对主服务器的同步操作需要通过向主服务器发送SYNC命令来完成，以下是SYNC命令的执行步骤：

  1. 从服务器向主服务器发送SYNC命令；
  2. 收到SYNC命令的主服务器执行BGSAVE命令，在后台生成一个RDB文件，并使用一个缓冲区记录从现在开始执行的所有写命令；
  3. 当主服务器的BGSAVE命令执行完毕时，主服务器会将BGSAVE命令生成的RDB文件发送给从服务器，从服务器接收并载入这个RDB文件，将自己的数据库状态更新至主服务器执行BGSAVE命令时的数据库状态。
  4. 主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新至主服务器数据库当前所处的状态。

2. 命令传播

在执行完同步操作之后，主从服务器之间数据库状态已经相同了。但这个状态并非一成不变，如果主服务器执行了写操作，那么主服务器的数据库状态就会修改，并导致主从服务器状态不再一致。

所以为了让主从服务器再次回到一致状态，主服务器需要对从服务器执行命令传播操作：主服务器会将自己执行的写命令，也即是造成主从服务器不一致的那条写命令，发送给从服务器执行，当从服务器执行了相同的写命令之后，主从服务器将再次回到一致状态。

 

3. redis2.8之前版本复制的缺陷

在Redis中，从服务器对主服务器的复制可以分为以下两种情况：

  1. 初次复制：从服务器以前没有复制过任何主服务器，或者从服务器当前要复制的主服务器和上一次复制的主服务器不同；
  2. 断线后重复制：处于命令传播阶段的主从服务器因为网络原因而中断了复制，但从服务器通过自动重连接重新连上了主服务器，并继续复制主服务器。

对于初次复制来说，旧版复制功能能够很好地完成任务，但对于断线后重复制来说，旧版复制功能虽然也能让主从服务器重新回到一致状态，但效率却非常低。

SYNC命令是非常消耗资源的，因为每次执行SYNC命令，主从服务器需要执行一下操作：

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

SYNC是一个如此消耗资源的命令，所以Redis最好在真需要的时候才需要执行SYNC命令

 

新版复制功能的实现

为了解决旧版复制功能在处理断线重复制情况时的低效问题，Redis从2.8版本开始，使用PSYNC命令代替SYNC命令来执行复制时的同步操作。

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

  1. 其中完整重同步用于处理初次复制情况：完整重同步的执行步骤和SYNC命令的执行步骤基本一样，它们都是通过让主服务器创建并发送RDB文件，以及向从服务器发送保存在缓冲区里面的写命令来进行同步；
  2. 而部分重同步则用于处理断线后重复制情况：当从服务器在断线后重新连接主服务器时，如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这些写命令，就可以将数据库更新至主服务器当前所处的状态

部分重同步实现

部分重同步功能由以下三个部分构成：

  1. 主服务器的复制偏移量（replication offset）和从服务器的复制偏移量；
  2. 主服务器的复制积压缓冲区（replication backlog）；
  3. 服务器的运行ID（run ID）

复制偏移量

执行复制的双方——主服务器和从服务器会分别维护一个复制偏移量：

  1. 主服务器每次向从服务器传播N个字节的数据时，就将自己的复制偏移量的值加上N；
  2. 从服务器每次收到主服务器传播来的N个字节的数据时，就将自己的复制偏移量的值加上N；

通过对比主从服务器的复制偏移量，程序可以很容易地知道主从服务器是否处于一致状态：

  1. 如果主从服务器处于一致状态，那么主从服务器两者的偏移量总是相同的；
  2. 相反，如果主从服务器两者的偏移量并不相同，那么说明主从服务器并未处于一致状态。

 

假设Slave A在短线之后立即重新连接master，并且成功，接下来slave A向master 发送PSYNC命令，master对比slave A的偏移量发现不相等，那么这时候是使用完全同步还是部分同步呢？如果部分同步的话，master如何补偿slave A在短线期间的数据呢？这就和下面所说的复制积压缓冲区有关。

复制积压缓冲区

复制积压缓冲区是由主服务器维护的一个固定长度（fixed-size）先进先出（FIFO）队列，默认大小为1MB。

和普通先进先出队列随着元素的增加和减少而动态调整长度不同，固定长度先进先出队列的长度是固定的，当入队元素的数量大于队列长度时，最先入队的元素会被弹出，而新元素会被放入队列。

当主服务器进行命令传播时，它不仅会将写命令发送给所有从服务器，还会将写命令入队到复制积压缓冲区里面，如图所示:

 

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

 

当从服务器重新连上主服务器时，从服务器会通过PSYNC命令将自己的复制偏移量offset发送给主服务器，主服务器会根据这个复制偏移量来决定对从服务器执行何种同步操作：

  1. 如果offset偏移量之后的数据仍然存在于复制积压缓冲区里面，那么主服务器将对从服务器执行部分重同步操作；
  2. 相反，如果offset偏移量之后的数据已经不存在于复制积压缓冲区，那么主服务器将对从服务器执行完整重同步操作。

复制积压缓冲区的大小

Redis为复制积压缓冲区设置的默认大小为1MB，如果主服务器需要执行大量写命令，又或者主从服务器断线后重连接所需的时间比较长，那么这个大小也许并不合适。如果复制积压缓冲区的大小设置得不恰当，那么PSYNC命令的复制重同步模式就不能正常发挥作用，因此，正确估算和设置复制积压缓冲区的大小非常重要。

复制积压缓冲区的最小大小可以根据公式second*write_size_per_second来估算：

  1. 其中second为从服务器断线后重新连接上主服务器所需的平均时间（以秒计算）；
  2. 而write_size_per_second则是主服务器平均每秒产生的写命令数据量（协议格式的写命令的长度总和）；

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

为了安全起见，可以将复制积压缓冲区的大小设2secondwrite_size_per_second，这样可以保证绝大部分断线情况都能用部分重同步来处理。至于复制积压缓冲区大小的修改方法，可以参考配置文件中关于repl-backlog-size选项的说明。

服务器运行ID

除了复制偏移量和复制积压缓冲区之外，实现部分重同步还需要用到服务器运行ID（run ID）：

  1. 每个Redis服务器，不论主服务器还是从服务，都会有自己的运行ID；
  2. 运行ID在服务器启动时自动生成，由40个随机的十六进制字符组成，例如53b9b28df8042fdc9ab5e3fcbbbabff1d5dce2b3；

 

当从服务器对主服务器进行初次复制时，主服务器会将自己的运行ID传送给从服务器，而从服务器则会将这个运行ID保存起来.

当从服务器断线并重新连上一个主服务器时，从服务器将向当前连接的主服务器发送之前保存的运行ID：

  1. 如果从服务器保存的运行ID和当前连接的主服务器的运行ID相同，那么说明从服务器断线之前复制的就是当前连接的这个主服务器，主服务器可以继续尝试执行部分重同步操作；
  2. 相反地，如果从服务器保存的运行ID和当前连接的主服务器的运行ID并不相同，那么说明从服务器断线之前复制的主服务器并不是当前连接的这个主服务器，主服务器将对从服务器执行完整重同步操作。

PSYNC命令的实现

PSYNC命令的调用方法有两种：

  1. 如果从服务器以前没有复制过任何主服务器，或者之前执行过SLAVEOF no one命令，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC ? -1命令，主动请求主服务器进行完整重同步（因为这时不可能执行部分重同步）；
  2. 相反地，如果从服务器已经复制过某个主服务器，那么从服务器在开始一次新的复制时将向主服务器发送PSYNC命令：其中runid是上一次复制的主服务器的运行ID，而offset则是从服务器当前的复制偏移量，接收到这个命令的主服务器会通过这两个参数来判断应该对从服务器执行哪种同步操作。

根据情况，接收到PSYNC命令的主服务器会向从服务器返回以下三种回复的其中一种：

  1. 如果主服务器返回+FULLRESYNC，那么表示主服务器将与从服务器执行完整重同步操作：其中runid是这个主服务器的运行ID，从服务器会将这个ID保存起来，在下一次发送PSYNC命令时使用；而offset则是主服务器当前的复制偏移量，从服务器会将这个值作为自己的初始化偏移量；
  2. 如果主服务器返回+CONTINUE，那么表示主服务器将与从服务器执行部分重同步操作，从服务器只要等着主服务器将自己缺少的那部分数据发送过来就可以了；
  3. 如果主服务器返回-ERR回复，那么表示主服务器的版本低于Redis 2.8，它识别不了PSYNC命令，从服务器将向主服务器发送SYNC命令，并与主服务器执行完整同步操作。

 

posted @ 2019-01-21 20:28  A-a  阅读(213)  评论(0)  编辑  收藏  举报