主从复制

1.复制概述

redis主从复制新旧版本过程图,如上所示

旧版本的初始复制和断线后复制都是全量复制,上图的复制过程已经一目了然,在这里文字叙述下新版本的复制

PSYNC命令触发的主节点响应有三种:

  1. +FULLRESYNC
  2. +CONTINUE
  3. -ERR
重点记录下+CONTINUE响应关键字,在了解之前首先需要了解几个概念
  • 复制偏移量(offset):
    主服务器向从服务器传送N个字节数据master_offset = master_offset+ N,从服务器接收N个字节数据slave_offset = slave_offset+N
    当master_offset = slave_offset是说明主从数据库状态一致
  • 复制积压缓冲区:
    由一个固定长度的FIFO队列组成,默认大小为1M;在命令传播阶段不止会将命令发送给从服务器,还会将写命令记录在复制积压缓冲区
    主服务器的复制积压缓冲区记录着最近传播的写命令,并且有每个字节的offset
    当接收客户端的PSYNC命令是会检查客户端带过来的复制偏移量是否在积压缓冲区中,如果在就是部分重同步否则就是全量重同步
  • 运行id
根据判断offset是否在复制积压缓冲区中就可以知道是全部还是部分重同步

2.复制拓扑图

  1. 一主一从
  2. 一主多从:可利用多个节点实施故障转移,适用于读多写少的情况;在写多的情况下会过度消耗网络带宽
  3. 树状主从:从节点不但可以从主节点复制还可以从从节点复制,减轻主节点的压力

3.复制过程

  1. 保存主节点信息
  2. 从节点通过每秒定时任务维护复制想过逻辑
  3. 发送ping命令检测主从之间的网络套接字是否可用,当前主节点是否可接受处理命令
  4. 权限验证
  5. 同步数据(全量和增量)
  6. 命令持续复制

高可用主从复制

在了解高可用的主从复制之前我们先看看普通主从复制的缺点:
  1. 主从复制,若主节点出现问题,则不能提供服务,需要人工修改配置将从变主
  2. 主从复制主节点的写能力单机,能力有限
  3. 单机节点的存储能力也有限

故障恢复:

1.主节点故障,从节点执行 slaveof no one后变成新主节点;

2.其它的节点成为新主节点的从节点,并从新节点复制数据;

3.需要人工干预,无法实现高可用。

1.哨兵内部数据结构

通过redis-sentinel ./sentinel.conf 会初始化一个普通redis服务器并使用Sentinel专用代码,之后会初始化Sentinel状态,就是如下图所示的结构
具体字段含义自行查找

在上面初始化Sentinel的状态之后Sentinel会创建对主从服务器的监控(命令连接和订阅连接),如下图所示

工作流程

  1. 主节点出现故障,主从失去连接复制失败
  2. 哨兵节点,定期发现出现故障的主节点
  3. 多个Sentinel节点对主节点故障达成一致,选出新的领导者负责故障转移
  4. 完成故障转移,更新拓扑图

3.三个定时任务

1.十秒一次发送INFO命令获取服务器信息,更新拓扑图

一般监听从服务器节点信息变化或者新加入从服务器,只需要给主服务器发送INFO命令,在主服务器的回复中会携带其从节点信息

2.两秒一次每个哨兵节点会向主从节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息,用于更新Sentinel字典

同时每个哨兵节点也会订阅该频道,来了解其它哨兵节点的信息及对主节点的判断,通过消息PUBLISH和SUBSCRIBE来完成的

3.每秒一次Sentinel会向每个与自己创建命令连接的实例发送PING命令,判断是否是主观下线

回复有+PONG、-LOADING、-MASTERDOWN,除了这几种其他的都是无效回复,如果在down-after-milliseconds配置时间内一直返回无效回复则会标记为无效节点

4.故障转移

在上面第三个定时任务,如果检测到主服务器是主观下线,这个时候当前Sentinel会向其他Sentinel发送
SENTINEL is-master-down-by-addr 命令,当其他Sentinel对当前命令回复Multi Bulk中down_state参数值为 1时表示同意客观下线,当同意客观下线的Sentinel为配置的quorum时则将服务器判定为客观下线,并对主服务器开始执行故障转移

步骤

1.使用raft算法选举领头Sentinel

2.选取新的主服务器

a).从最近一直都有通信的从服务器中选取 b).选取优先级最高的从服务器 c).选取复制偏移量最大的从服务器

3.让从服务器复制新主

4.让已下线主服务变为新主的从服务器