标签：str 自己 span 执行命令 判断 mil run 同步请求 文件
几个常见的概念
在讲解主从复制原理之前我们首先要了解几个基本的概念，这有利于我们立交主从复制的过程：
Redis的复制功能分为同步和命令传播两个操作。
注意，redis2.8以前的版本和redis2.8之后的版本在这一步有些不同，主要是新版本中有偏移量的维护，其他基本一致，在这里是以新版本为主的。
当客户端向从服务器发送slaveof命令，要求从从服务器复制主服务器时，从服务器首先进行同步操作，也就是，将从服务器的数据库状态更新至主服务器的当前所处的数据库状态。
从服务器对主服务器的同步操作需要哦通过向主服务器发送PSYNC命令实现，当然，使用PSYNC命令进行从服务器第一次同步（完整重同步）和非第一次的同步（包括再次同步和断开重连后的同步都是使用部分重同步）是有些不同：
第一次复制
1.从服务器向主服务器发送PSYNC命令。
2.收到PSYNC命令的主服务器执行BGSAVE命令，在手台生成RDB文件，并使用一个缓冲区记录从现在开始执行的所有命令。
3.当主服务的BGSAVE命令执行完毕时，主服务器会将BGSAVE命令生成的RDB文件发送给从服务器，从服务器接受并载入这个RBD文件，将自己的数据库状态更新至住服务器执行BGSAVE命令时的数据库状态
4.主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新至主服务器数据库当前所处的状态。
非第一次复制
如果从服务器已经从某个主服务器上复制过，那么从服务器在开始一次新的复制的时候将向主服务器发送PSYNC <runid> <offset>命令，其中runid是上一次复制的主服务器的id，而offset则是偶从服务器当前的复制偏移量，接受到这个命令的主服务器会通过这两个参数判断应该对从服务器执行那种同步操作。
1.
2.
3.
当同步操作执行完后，主从服务器两者的数据库将达到一致状态，但是这种一致状态并不是一成不变的，当主服务执行客户端发送的命令的时，主服务器的数据库就有可能会被修改，并导致主从服务器状态不一致。
这个时候为了让主从服务器的状态再次回到一致，主服务器需要对从服务器执行命令传播操作：主服务器会将自己执行的写命令，也即是造成主从服务器不一致的那条写命令，发送给从服务器执行，当从服务器执行了相同的写命令之后，主从服务器将再次回到一致状态。
执行复制的双方-主服务器和从服务器分别会维护一个复制偏移量。在进行部分重同步的时候就是通过复制偏移量来实现的。
主服务器每次向从服务器传播N个字节的数据时，就将自己的复制偏移量的值加上N
复制积压缓冲区是有主服务器维护的一个固定长度的先进先出（FIFO）的队列，默认是1M。这里面回报纯这一部分最近传播的写命令，并且复制积压缓冲区会为队列中的每个字节记录响应的复制偏移量。
当某个从服务器断开重新连接上后，从服务器会通过PSYNC命令将自己的复制偏移量offset和主服务id发送给主服务，主服务器先用发送来的主服务id和自己的id进行比较然后拿发送过来的offset来和复制积压缓冲区的比较，如果offset偏移量之后的数据在复制积压缓冲区，那么主服务器将对从服务器执行部分重同步操作，如果不在复制积压缓冲区，那么主服务器将对从服务器进行完整重同步操作。
主从复制的原理
其实介绍完上面的一些概念，主从复制的原理已经出来了，下面咱们再总结一下（第一次执行主从复制为例）。
客户端想从服务器发送slaveof命令
1.从服务器向主服务器发送PSYNC ? -1命令，请求主服务器执行完整重同步操作
2.主服务器在接收到完整重同步请求后，在后台重启一个线程执行BGSAVE命令，也就是对才是数据快照生成RDB文件，并向从服务器返回+FULLRESYNC 主服务器id 主服务器此时的偏移量等数据，而主线程仍然可以接受请求，并将请求放到缓冲区
3.当主服务器的BGSAVE命令执行完毕时，主服务器将生成RDB文件发送给从服务器，从服务器完成此文件的接受和载入，将自己的数据库状态更新至住服务器执行BGSAVE命令时的数据库状态
4.主服务器将记录在缓冲区中的所有写命令发送给从服务器，主服务器修改自己的复制偏移量，从服务器接收成功后，也会修改自己的复制偏移量，这样主从服务器的数据就保持一致了
对于如果不是第一次执行复制的情况就是执行部分重同步的操作，这里不在累述。
标签：str 自己 span 执行命令 判断 mil run 同步请求 文件
原文地址：https://www.cnblogs.com/htyj/p/11717039.html
