Redis高可用的原因(二) -- 主从模式

在分布式系统中 , 涉及一个很关键的问题 “单点问题” – 如果某个服务器只有一个节点 , 那么这个服务器挂了之后 , 后续就无法继续提供服务了 . 因此 , 在分布式系统中 , 一般会部署多个节点 , 来提供更稳定 , 更高效的服务 .

主从模式

部署多个Redis节点的方式一般会使用 “主从模式” , 即部署多个Redis节点 , 其中一个Redis节点为主节点 (master Redis), 其他节点为从节点 (slave Redis) . 这种模式的特点是 : 只有主节点可以写数据 , 从节点只能读数据 .

1. 主从模式的好处

• 读写分离 : 使用主从模式 , 可以实现数据的读写分离 , 提高服务器的读写负载能力
• 数据冗余 : 使用主从模式 , 可以实现数据备份 .
• 负载均衡 : 在读多写少的场景 , 多个Redis从节点可以分担读数据请求 , 减轻Redis的压力
• 故障恢复 : 主节点出现问题时 , 可以由从节点提供服务 , 实现故障恢复 .

2. 怎么建立主从关系

• 一个节点执行slaveof no one 之后 , 该节点就会成为主节点
• 一个节点执行slaveof 主节点ip 主节点端口 之后 , 该节点就会成为主节点的从节点

使用命令建立的主从关系是暂时的 , 当Redis重启之后 , 这个主从关系就会失效 , 要实现持久化的主从关系 ,就要在redis的配置文件中进行配置 .

3. 怎么断开主从关系

• 从节点执行slaveof no one 命令之后 , 从节点成为一个独立的主节点 . – 执行完命令后的从节点不会删除从主节点复制来的数据 , 但是无法获取后续主节点更新的新数据
• 一个节点可以执行 slaveof ip 端口 命令 , 成为某个节点的从节点 – ip和端口是节点要投靠的新节点的ip和端口
• 主节点挂了 , 在没有哨兵机制的前提下 , 从节点是不会自动晋升为主节点的 , 需要人工干预 , 重启主节点或者选择从节点作为新的主节点

4. 主从模式的拓扑结构

4.1 链式结构

slaveA会从master节点同步数据 , slaveB会从slaveA同步数据 , slaveC会从slaveB同步数据 . – 链越长 ,同步数据所需要的时间就越长
该结构真正的主节点只有master , 其他节点全部为从节点

4.2 树形结构

每个节点都会从其父节点同步数据 – 层次越高 , 同步数据所需要的时间就越长

5. 主从节点数据复制的方式

当节点之间建立主从关系之后 , 从节点就要从主节点之中同步数据 . 数据的同步方式分为三种

• 全量复制 : 从节点和主节点第一次建立连接 , 主节点将全部数据全部发送给从节点
• 增量复制 : 从节点和主节点断开连接后 , 从节点需要从主节点中同步在断开连接期间未同步的数据
• 实时复制 : 从节点和主节点已经同步好了数据 , 主从一致 , 但是之后 , 主节点这边收到了新的修改数据的请求 , 主节点上的数据也会随之改变 , 需要同步给从节点

5.1基础概念

在了解不同的同步方式之前 , 需要先了解以下名词 , 才能更好理解数据同步

• replication id : 简称replid , 每个Redis节点 , 都有一个replid , 当从节点和主节点建立连接之后 , 主节点就会将自己的replid赋值给从节点 , 因此 , 在主从关系中 , 从节点的replid始终和主节点保持一致
• repl_baklog : 积压缓冲区 , 一个基于数组构建的环形队列 , 存放主节点要同步给从节点的命令 .
• offset : 偏移量 , 主从节点各自维护一个offset , 主节点的offset是要同步给从节点的数据的进度 , 从节点的offset是实际同步的数据的进度 . 可以理解为从节点从主节点中同步数据的进度 . 当主从节点的offset一致时 ,说明两者数据一致
  

5.2 全量复制

全量复制 : 从节点和主节点第一次建立连接 , 主节点将全部数据全部发送给从节点

问题1 : 怎么判断主从节点是不是第一次连接

从节点发送psync命令给主节点 (携带replid 和 offset) , 主节点根据replid是否一致判断该节点之前是否连接过 , 如果不一致 , 那么就是第一次连接 , 如果一致 , 就不是第一次连接

问题2 : 全量复制的步骤

1. 从节点发送psync命令给主节点
2. 主节点根据replid 判断是第一次连接 , 就会执行bgsave命令生成RDB文件
3. 主节点将RDB文件发送给从节点
4. 从节点接收到文件后 , 会清空本地数据 , 加载RDB文件
5. 在从节点加载RDB文件的同时 , 主节点可能会收到新的修改数据的命令 , 将命令存储在repl_baklog缓冲区中
6. 从节点加载数据结束之后 , 就会根据offset从repl_baklog读取还未执行的命令

5.3 增量复制

增量复制 : 从节点和主节点断开连接后 , 从节点需要从主节点中同步在断开连接期间未同步的数据

从节点因为网络问题 , 和主节点短暂断开一段时间之后 , 从节点向主节点再次发起psync命令进行连接

1. 从节点发送psync命令给主节点
2. 主节点根据replid 判断不是第一次连接 , 再次判断offset是否落后于主节点的offset
3. 如果offset落后且此时的repl_baklog没有发生数据覆盖
4. 从节点就会根据offset从repl_baklog读取还未执行的命令

注意 : 如果从节点断开时间过长 , 缓冲区数据被覆盖重写 , 那么从节点就要进行全量同步

5.4 实时复制

实时复制 : 从节点和主节点已经同步好了数据 , 主从一致 , 但是之后 , 主节点这边收到了新的修改数据的请求 , 主节点上的数据也会随之改变 , 需要同步给从节点

主从节点之间建立TCP长连接 , 然后主节点将自己收到的修改数据的请求 , 通过上述连接 , 发送给从节点 , 从节点 再根据修改请求 , 修改内存中的数据

6. 怎么提高数据同步的效率

• 在master配置中配置repl-diskless-sync yes 启用无磁盘复制 , 直接将数据进行网络传输 , 避免全量同步时的磁盘IO(主/从节点不用将RDB文件写到磁盘 , 也不用从磁盘读取数据 , 主节点直接将数据进行网络传输 , 从节点直接读取数据) .
• Redis单节点的内存占用不要太大 , 减少RDB导致的过多磁盘IO
• 提高Repl_baklog的大小 , 发现slave宕机时尽快恢复 , 尽可能避免全量同步