[Redis][主从复制][中]详细讲解

1.原理

1.建立复制 && 复制过程

• 保存主节点(master)的信息
  • 开始配置主从同步关系之后，从节点只保存主节点的地址信息，此时建⽴复制流程还没有开始
  • 在从节点6380执⾏info replication可以看到如下信息
    • ip和port被保存下来，但是主节点的连接状态是下线状态

    master_host: 127.0.0.1
    master_port: 6379
    master_link_status: down
    

• 主从建立连接：
  • 从节点(slave)内部通过每秒运⾏的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与主节点建⽴基于TCP的⽹络连接
  • 如果从节点⽆法建⽴连接，定时任务会⽆限重试直到连接成功或者⽤⼾停⽌主从复制
• 发送ping命令：
  • 发送ping命令。连接建⽴成功之后，从节点通过ping命令确认主节点在应⽤层上是⼯作良好的
  • 如果ping命令的结果pong回复超时，从节点会断开TCP连接，等待定时任务下次重新建⽴连接
• 权限验证：
  • 如果主节点设置了requirepass参数，则需要密码验证，从节点通过配置 masterauth参数来设置密码
  • 如果验证失败，则从节点复制将会停⽌
• 同步数据集：
  • 对于⾸次建⽴复制的场景，主节点会把当前持有的所有数据全部发送给从节点，这步操作基本是耗时最⻓的
  • 所以⼜划分称两种情况：全量同步和部分同步
• 命令持续复制：
  • 当从节点复制了主节点的所有数据之后，针对之后的修改命令，主节点会持续的把命令发送给从节点，从节点执⾏修改命令，保证主从数据的⼀致性
    

2.数据同步 psync

• Redis使用psync命令完成主从数据同步，同步过程分为：全量复制和部分复制
  • 全量复制：
    • ⼀般⽤于初次复制场景，Redis早期⽀持的复制功能只有全量复制，它会把主节点全部数据⼀次性发送给从节点
    • 当数据量较⼤时，会对主从节点和⽹络造成很⼤的开销
  • 部分复制：
    • ⽤于处理在主从复制中因⽹络闪断等原因造成的数据丢失场景
    • 当从节点再次连上主节点后，如果条件允许，主节点会补发数据给从节点
    • 因为补发的数据远⼩于全量数据，可以有效避免全量复制的过⾼开销
• PSYNC语法：PSYNC replication offset
  • 如果replicationid设为?并且offset设为-1，此时就是在尝试进⾏全量复制
  • 如果replicationid offset设为了具体的数值，则是尝试进⾏部分复制
• replicationid/replid(复制id)：
  • 主节点的复制id，主节点重新启动，或者从节点晋级成主节点，都会生成一个replicationid
    • 同一个节点，每次重启，生成的replicationid也会变化
  • 从节点和主节点建立连接之后，就会获取到主节点的replicationid
  • 通过info replication即可看到replicationid

    127.0.0.1:6379> info replication
    # Replication
    role:master
    connected_slaves:0
    master_replid:1da596acecf5a34b4b2aae45bd35be785691ae69
    master_replid2:0000000000000000000000000000000000000000
    master_repl_offset:0
    second_repl_offset:-1
    repl_backlog_active:0
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:0
    repl_backlog_histlen:0
    

  • 关于master_replid和master_replid2，每个节点需要记录两组master_replid，这个设定解决的问题场景是这样的：
    • 比如当前有两个节点A和B，A为master，B为slave
      • 此时B就会记录A的master_replid
    • 如果网络出现抖动，B以为A挂了，B自己就会成为主节点，于是B给自己分配了新的master_replid，此时就会使用master_replid2来保存之前A的master_replid
      • 后续如果网络恢复了，B就可以根据master_replid2找回之前的主节点
      • 后续如果网络没有恢复，B就按照新的master_replid自成一派，继续处理后续的数据
  • 明辨replid和runid？
    • runid：主要用在支撑实现Redis哨兵这个功能，和主从复制没关系
    • replid：主要在主从复制中起到作用
• offset(偏移量)：
  • 参与复制的主从节点都会维护⾃⾝复制偏移量
    • 主节点(master)在处理完写⼊命令后，会把命令的字节⻓度做累加记录，统计信息在info replication中的master_repl_offset指标中

    127.0.0.1:6379> info replication
    # Replication
    role:master
    ...
    master_repl_offset:1055130
    

  • 从节点(slave)每秒钟上报⾃⾝的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量

     127.0.0.1:6379> info replicationconnected_slaves:1slave0:ip=127.0.0.1,port=6380,state=online,offset=1055214,lag=1...
    

  • 从节点在接受到主节点发送的命令后，也会累加记录⾃⾝的偏移量，统计信息在info replication中的slave_repl_offset指标中

    127.0.0.1:6380> info replication
    # Replication
    role:slave
    ...
    slave_repl_offset:1055214
    

3.复制偏移量维护

• 通过对⽐主从节点的复制偏移量，可以判断主从节点数据是否⼀致
  

• replid+offset共同标识了⼀个"数据集"

  • 如果两个节点，他们的replid和offset都相同，则这两个节点上持有的数据，就⼀定相同

4.psync 运行流程

• 从节点发送psync命令给主节点，replid和offset的默认值分别是?和-1

• 主节点根据psync参数和自身数据情况决定响应结果

  • 如果回复+FULLRESYNC replid offset，则从节点需要进⾏全量复制流程
  • 如果回复+CONTINEU，则从节点进⾏部分复制流程
  • 如果回复-ERR，说明Redis主节点版本过低，不⽀持psync命令
    • 从节点可以使⽤sync命令进⾏全量复制
      

• 说明：

  • psync⼀般不需要⼿动执⾏，Redis会在主从复制模式下⾃动调⽤执⾏
    • 从节点负责执行psync，从节点从主节点这边拉取数据
  • sync会阻塞redisserver处理其他请求，psync则不会