《Redis设计与实现》阅读笔记10-复制.docxVIP

? ? 《Redis设计与实现》阅读笔记10-复制 ? ? 14 复制 在redis中使用slaveof命令，可以使得服务器去复制另一个服务器，成为那个服务器的从服务器，称为主从复制 14.1 旧版复制功能 旧版复制的实现由两种方式组成 同步：通过发送主服务器的rdb文件给从服务器与缓冲区保存后续写命令使得主从服务器状态一致 命令传播：主从服务器状态一致后，主服务器发送后续修改数据库的命令给从服务器保证主从服务器状态一致 14.1.1 同步 当一个服务器使用slaveof命令成为另一个服务器的从服务器时，使用SYNC命令启动同步操作，过程如下 从服务器发送SYNC命令给主服务器 主服务器执行BGSAVE命令生成rdb文件，并使用一个缓冲区保存后续写命令 从服务器使用主服务器发送过来的rdb文件同步到和主服务器状态一致 主服务将缓冲区中的写命令发送给从服务器执行，使得其状态完全一致 14.1.2 命令传播 为了保证主从服务器状态是一致的，使用同步命令初始化后，后续的持续性的一致性需要命令传播来保证。命令传播是指在主服务器执行写命令时也同时会把这个命令发送给从服务器，让从服务器再执行一遍。 14.2 旧版复制功能的缺陷 在主从服务器正常连接后，若突然出现主从服务器的断开（非正常断开），在重新连接以后，在断开时间段中由于命令传播功能无法正常执行，导致主从服务器的数据库状态存在差异，此时需要重写进行同步操作。 此时的同步操作会同步所有数据，但其实主从服务器之间只差了断开期间的几条指令。之前的大部分数据完全一样，而再次执行同步操作就显得性价比极低。，并且SYNC命令是一个非常耗费资源的操作{包括一次rdb文件生成（消耗cpu，内存，磁盘I/O资源），rdb文件的发送（带宽与流量），从服务器载入RDB文件（从服务器阻塞）} 14.3 新版复制的实现 新版复制（redis2.8版本以后）使用PSYNC命令代替SYNC命令来执行复制时的同步操作，PSYNC命令具有完整全同步和部分重同步两种模式 完整全同步和SYNC命令的同步一样，会使用rdb文件全部复制主服务器的所有数据 部分重同步处理旧版复制的缺陷，利用复制偏移量，复制积压缓冲区，服务器运行ID实现只复制需要部分的功能，而不会因为缺少部分数据，而复制所有数据 14.4 部分重同步的实现 部分重同步利用复制偏移量，复制积压缓冲区，服务器运行ID实现只复制需要部分的功能 14.4.1 复制偏移量 主服务器和从服务器都维护了一个复制偏移量，主服务器执行写操作，写N个字节数据，就让主服务器的复制偏移量增加N，每次主服务器向从服务器执行命令传播时，传播N个字节数据，就让从服务器的复制偏移量增加N。 若主从服务器状态一致，那他们的复制偏移量总是一样。 14.4.2 复制积压缓冲区 复制积压区是一个固定长度的循环队列，内部储存的数据结构，每个都保存着偏移量与该偏移量对应一个字节的写命令内容 偏移量 … 187 188 189 190 191 192 193 194 195 196 197 … 字节值 … ‘*’ 3 ‘\r’ ‘\n’ ‘$’ 3 ‘\r’ ‘\n’ ‘S’ ‘E’ ‘T’ … 当从服务器重新连接以后，会发送自己保存的主服务器运行ID与自己的复制偏移量发送给主服务器，若主服务器运行ID与从服务器发送的断线前的主服务运行ID一致，且从服务器的复制偏移量在复制积压缓冲区中未被冲走（从服务器偏移量+1还在循环队列中有保存），就会根据偏移量差，在复制积压缓冲区中取命令，并执行，然后更新从服务器的复制偏移量，使得主从服务器状态一致。 关于缓存区大小的选择：缓冲区的大小一般根据，服务器重连平均时间与主服务器平均每秒执行写命令数量来估算，选择的大小一般都需要大于这两者的乘积，来保证大多数从服务器重连以后是执行部分重同步，达到节约资源的目的 14.4.3 服务器运行ID 不管是从服务器还是主服务器都有自己的运行ID（四十个随机的16进制字符），从服务器会保存当前连接的主服务器的运行ID，保存的主服务器运行ID用于从服务器使用PSYNC命令时，若从服务器保存的有之前的主服务器运行ID，会把这个运行ID一起发给主服务器，若主服务器发现这个ID和自己的运行ID一样，就会考虑复制偏移量在缓冲区中是否有保存，来决定执行部分重同步还是完整重同步，若运行ID不一样，默认使用完整重同步。 14.5 PSYNC命令的实现 现在，来完整了解PSYNC的实现流程 从服务器请求复制 如果一个服务器成为从服务器时，没有保存主服务器运行ID（第一次成为主服务器或者执行过SLAVEOF no one命令），那么服务器向主服务器发送PSYNC ？ -1，主动请求完整重同步 如果一个服务器成为从服务器时，保存的有主服务器运