（进阶篇）Redis6.2.0 集群主从复制_原理剖析_02

Myth丶恋晨 2022-10-12 12:15 72阅读 0赞

### 文章目录 ###

*   *   *   *   *  一、主从复制流程
                 *   *  1. 主从复制流程图
                     *  2. 主从复制日志
                 *  二、主从复制信息剖析
                 *   *  2.1. 主节点信息剖析
                     *  2.2. 从节点信息剖析
                 *  三、关键术语
                 *   *  3.1. 复制功能开启
                     *  3.2. 全量复制场景
                     *  3.3. 主从复制异步性
                     *  3.4. 过期key的处理
                     *  3.5. 加速复制

##### 一、主从复制流程 #####

###### 1. 主从复制流程图 ######

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDgxNjczOA_size_16_color_FFFFFF_t_70]  
第一条线（全量同步）：  
①slave从节点发送FULL SYNC全量同步请求命令  
②master执行bgsave  
③将内存中数据通过copy-on-write方式 写入到磁盘  
④将磁盘的数据生成rdb快照  
⑤master把rdb快照文件发送给slave从节点  
⑥从节点丢弃旧的数据，接收新的rdb快照文件  
⑦加载rdb文件  
⑧slave复制完成

第二条线（增量同步）：  
①slave从节点发送FULL SYNC全量同步请求命令  
②master执行bgsave  
③主节点会往从节点连接缓冲区写一份数据，同时往repl\_backlog也写一份数据，所有从节点共享同一份repl\_backlog  
④slave节点接收缓存区的命令  
⑤增量数据同步/复制完成

###### 2. 主从复制日志 ######

master复制日志查看

* Ready to accept connections # 准备就绪等待链接
    * Replica 1xxx.xxx.xxx.101:6379 asks for synchronization
      # 102节点向主节点发起了一个全量resync 的请求
    * Full resync requested by replica 1xxx.xxx.xxx.101:6379
      # 主节点创建缓冲区，
    * Replication backlog created, my new replication IDs are 'b1f446c9ea7c0d5e95c8c47f31b000000000000000000000000000'
      # 通过BGSAVE 将数据写入磁盘，生成rdb快照，发给子节点
    * Starting BGSAVE for SYNC with target: disk
    * Background saving started by pid 11978
    * DB saved on disk
      # 通过copy-on-write的方式将4m数据写入磁盘
    * RDB: 6 MB of memory used by copy-on-write
    * Background saving terminated with success
      # 101 节点的复制结束了 子节点加载rdb快照文件读取数据
    * Synchronization with replica 1xxx.xxx.xxx.101:6379 succeeded
    * Replica 1xxx.xxx.xxx.102:6379 asks for synchronization
    * Full resync requested by replica 1xxx.xxx.xxx.102:6379
    * Starting BGSAVE for SYNC with target: disk
    * Background saving started by pid 11979
    * DB saved on disk
    * RDB: 4 MB of memory used by copy-on-write
    * Background saving terminated with success
    * Synchronization with replica 1xxx.xxx.xxx.102:6379 succeeded
    # Disconnecting timedout replica: 1xxx.xxx.xxx.101:6379
    # Connection with replica 1xxx.xxx.xxx.101:6379 lost.
    # Disconnecting timedout replica: 1xxx.xxx.xxx.102:6379

##### 二、主从复制信息剖析 #####

> 通过什么可以查看主从节点信息呢？  
> info replcatipon

###### 2.1. 主节点信息剖析 ######

[root@bigdata01 bin]# /usr/local/redis/bin/redis-cli -a 123456
    Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
    127.0.0.1:6379> info replication
    # Replication
    role:master # 角色主节点
    connected_slaves:2 #它所连接到的从节点的数量
    # 从节点ip地址、 端口、状态：在线 当前从节点读取命令的偏移量 延迟时间：单位:秒
    #offset指的是从节点已经复制的命令偏移量是266
    # 这里的offset=master_repl_offset说明主从偏移量是一致的
    slave0:ip=1xxx.xxx.xxx.101,port=6379,state=online,offset=266,lag=1 #当前连接从01 slave节点信息
    slave1:ip=1xxx.xxx.xxx.102,port=6379,state=online,offset=266,lag=1 #当前连接从02 slave节点信息
    master_failover_state:no-failover
    # 主从的id
    master_replid:b1f446c9ea7c0d5e95c8c47f31bb007cea158ce8
    # 主从发生变化之后id
    master_replid2:0000000000000000000000000000000000000000
    # 主节点会把所有的命令转换成子字节。写到队里额里面，最终写入的值就是master_repl_offset
    # 主节点已写入的命令偏移量是266
    master_repl_offset:266
    # 判断是否全量复制的标识
    second_repl_offset:-1
    
    # 2.8之后 缓冲区
    repl_backlog_active:1 # 是否开启缓冲区 1-开启 0-关闭
    repl_backlog_size:1048576 # 缓冲区大小 1m，可以调控
    repl_backlog_first_byte_offset:1 # 从偏移量为1开始写入
    repl_backlog_histlen:266 # 当前缓存冲区长度
    127.0.0.1:6379>

###### 2.2. 从节点信息剖析 ######

[root@bigdata02 ~]# /usr/local/redis/bin/redis-cli -a 123456
    Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
    127.0.0.1:6379> info replication
    # Replication
     # 角色
    role:slave
    # 主节点ip
    master_host:1xxx.xxx.xxx.100
    # 主节点端口
    master_port:6379
    # 主节点当前状态
    master_link_status:up
    # 主从复制最后一次 4秒之前
    master_last_io_seconds_ago:4
    # 现在主从同步状态 0-未同步 1-正在同步
    master_sync_in_progress:0
    # 从节点复制的偏移量
    slave_repl_offset:3xxx
    # 从节点在选举时，成为主节点的权重优先级，这个参数越大，晋升主节点的优先级越高
    slave_priority:100
    # 从节点只读模式是否开启 1-开启 0-未开启
    slave_read_only:1
    # 从节点连接从节点数量
    connected_slaves:0
    master_failover_state:no-failover
    # 连接主节点的id
    #当前主节点宕机后master_replid会变成一个信心的，master_replid2存储老的主节点master_replid
    master_replid:b1f446c9ea7c0d5e95c8c47f31bb007cea158ce8
    master_replid2:0000000000000000000000000000000000000000
    # 主节点写入的偏移量
    master_repl_offset:3xxx
    second_repl_offset:-1
    repl_backlog_active:1
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:1
    repl_backlog_histlen:3xxx
    127.0.0.1:6379>

##### 三、关键术语 #####

###### 3.1. 复制功能开启 ######

通过什么配置项开启主从之间的复制功能呢?  
slaveof  
在从节点的配置中添加slaveof，从节点就会识别主节点是谁？跟主节点建立连接，然后开始同步数据。  
同步数据就是主从复制。复制的又分为全量复制和增量复制2种概念。

###### 3.2. 全量复制场景 ######

全量复制：从节点把主节点的数据全量复制过来  
发生的场景：  
1.初始化环境(刚搭建完主从复制集群，初始化主节点数据，从节点全量复制)  
2.新增从节点，需要把主节点数据全量复制过来，才能对外提供读服务  
3.在redis2.8之前，主节点故障(run\_id发生变化)，重新选举主节点，从节点为了保证安全性和一致性就会全量复制。  
假设如果数据没问题，进行一次全量复制就是多余的。  
在2.8之后，多了一个second\_repl\_offset为了避免主从节点发生变化或者故障转移都要全量复制。就会把主节点的偏移量记录下来，当重新选择举主节点后，就会先判断偏移量，根据偏移量做增复制。  
例如：  
从节点偏移量2590  
主节点偏移量2591  
主从节点偏移量相差1  
就会只同步1偏移量而不会全量复制了

增量复制：

*  增量复制是Slave初始化后开始正常工作时，主服务器发生的写操作同步到从服务器的过程。
 *  复制过程是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

###### 3.3. 主从复制异步性 ######

*  主从复制对于主从redis服务器是非阻塞的，当从服务器在进行主从复制过程中，主redis仍然可以处理外界的访问请求。
 *  主从复制对于从redis服务器是非阻塞，从redis在进行主从复制过程中也可以接收外界的查询请求，**只不过这时候从redis返回以前的数据。**

主从复制过程，主节点是非阻塞的，复制的流程中，主节点开启了一个后台子守护进程去做主从复制的，比如，bgsave、生成rdb快照、发送等等。同时，当前服务器的主节点仍然可以对外提供读写服务，这时他的异步性。  
从节点也是一样，比如，从节点正在复制主节点的数据，这个sync同步也是异步的，复制的过程中就会有问题。  
什么问题呢？  
比如，正在复制，这时一个查询请求发过来，就会查询的是老数据，这里面就会有脏读、数据不一致的问题。

###### 3.4. 过期key的处理 ######

**Slave不睡让key过期**，而是等待Master让KEY过期。当Master让KEY过期是，它会合成一个**DEL命令并传输到所欲的SLave节点。**

###### 3.5. 加速复制 ######

默认情况下，master节点接收SYNC命令后，执行BGSAVE操作，将数据先保存到磁盘，如果磁盘性能差，那么**写入磁盘会消耗大量的性能，**因此，在redis2.8.18时进行改进，可以设置**无需写入磁盘的直接发送RDB快照给slave**，加快复制速度。

修改配置：**repl\_diskless-sync yes (默认no)**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDgxNjczOA_size_16_color_FFFFFF_t_70]: /images/20221005/26caba630af944d19ba7aedaccc810bf.png