摘要：Redis在主从模式下会有许多问题须要思考，这里写了一些对于redis在多服务器下的一些问题剖析和总结。

Redis单节点存在单点故障问题，为了解决单点问题，个别都须要对redis配置从节点，而后应用哨兵来监听主节点的存活状态，如果主节点挂掉，从节点能持续提供缓存性能。主从配置联合哨兵模式能解决单点故障问题，进步redis可用性。从节点仅提供读操作，主节点提供写操作。对于读多写少的情况，可给主节点配置多个从节点，从而进步响应效率。

主从复制过程：

  • 从节点执行slaveofmasterIP，保留主节点信息
  • 从节点中的定时工作发现主节点信息，建设和主节点的socket连贯
  • 从节点发送Ping信号，主节点返回Pong，两边能相互通信
  • 连贯建设后，主节点将所有数据发送给从节点（数据同步）
  • 主节点把以后的数据同步给从节点后，便实现了复制的建设过程。接下来，主节点就会继续的把写命令发送给从节点，保障主从数据一致性。

Redis的数据同步过程：

redis2.8之前应用syncrunId同步命令，redis2.8之后应用psyncrunId命令。

两者不同在于，sync命令仅反对全量复制过程，psync反对全量和局部复制。

介绍同步之前，先介绍几个概念：

runId：每个redis节点启动都会生成惟一的uuid，每次redis重启后，runId都会发生变化。

offset：主节点和从节点都各自保护本人的主从复制偏移量offset，当主节点有写入命令时，offset=offset+命令的字节长度。从节点在收到主节点发送的命令后，也会减少本人的offset，并把本人的offset发送给主节点。这样，主节点同时保留本人的offset和从节点的offset，通过比照offset来判断主从节点数据是否统一。

repl_backlog_size：保留在主节点上的一个固定长度的先进先出队列，默认大小是1MB。

主节点发送数据给从节点过程中，主节点还会进行一些写操作，这时候的数据存储在复制缓冲区中。从节点同步主节点数据实现后，主节点将缓冲区的数据持续发送给从节点，用于局部复制。

主节点响应写命令时，岂但会把命名发送给从节点，还会写入复制积压缓冲区，用于复制命令失落的数据补救。

下面是psync的执行流程：

从节点发送psyncrunId命令，主节点有三种响应：

FULLRESYNC：第一次连贯，进行全量复制

CONTINUE：进行局部复制

ERR：不反对psync命令，进行全量复制

全量复制和局部复制的过程

下面是全量复制的流程。次要有以下几步：

从节点发送psync ? -1命令（因为第一次发送，不晓得主节点的runId，所以为?，因为是第一次复制，所以offset=-1）。

主节点发现从节点是第一次复制，返回FULLRESYNC {runId} {offset}，runId是主节点的runId，offset是主节点目前的offset。

从节点接管主节点信息后，保留到info中。

主节点在发送FULLRESYNC后，启动bgsave命令，生成RDB文件（数据长久化）。

主节点发送RDB文件给从节点。到从节点加载数据实现这段期间主节点的写命令放入缓冲区。

从节点清理本人的数据库数据。

从节点加载RDB文件，将数据保留到本人的数据库中。

-如果从节点开启了AOF，从节点会异步重写AOF文件。

对于局部复制有以下几点阐明：

1、局部复制次要是Redis针对全量复制的过高开销做出的一种优化措施，应用psyncrunId命令实现。当从节点正在复制主节点时，如果呈现网络闪断或者命令失落等异常情况时，从节点会向主节点要求补发失落的命令数据，主节点的复制积压缓冲区将这部分数据间接发送给从节点，这样就能够放弃主从节点复制的一致性。补发的这部分数据个别远远小于全量数据。

2、主从连贯中断期间主节点仍然响应命令，但因复制连贯中断命令无奈发送给从节点，不过主节点内的复制积压缓冲区仍然能够保留最近一段时间的写命令数据。

3、当主从连贯复原后，因为从节点之前保留了本身已复制的偏移量和主节点的运行ID。因而会把它们当做psync参数发送给主节点，要求进行局部复制。

4、主节点接管到psync命令后首先核查参数runId是否与本身统一，如果统一，阐明之前复制的是以后主节点；之后依据参数offset在复制积压缓冲区中查找，如果offset之后的数据存在，则对从节点发送+COUTINUE命令，示意能够进行局部复制。因为缓冲区大小固定，若产生缓冲溢出，则进行全量复制。

5、主节点依据偏移量把复制积压缓冲区里的数据发送给从节点，保障主从复制进入失常状态。

Redis主从复制会存在以下问题：

  • 一旦主节点宕机，从节点降职为主节点，同时须要批改利用方的主节点地址，还须要命令所有从节点去复制新的主节点，整个过程须要人工干预。
  • 主节点的写能力受到单机的限度。
  • 主节点的存储能力受到单机的限度。
  • 原生复制的弊病在晚期的版本中也会比较突出，比方：redis复制中断后，从节点会发动psync。此时如果同步不胜利，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的卡顿。

所以用哨兵解决以上问题。

哨兵的性能

Redis Sentinel（哨兵）次要性能包含主节点存活检测、主从运行状况检测、主动故障转移、主从切换。Redis Sentinel最小配置是一主一从。

Redis的Sentinel零碎能够用来治理多个Redis服务器，该零碎能够执行以下四个工作：

  • 监控：一直查看主服务器和从服务器是否失常运行。
  • 告诉：当被监控的某个redis服务器呈现问题，Sentinel通过API脚本向管理员或者其余应用程序发出通知。
  • 主动故障转移：当主节点不能失常工作时，Sentinel会开始一次主动的故障转移操作，它会将与生效主节点是主从关系的其中一个从节点降级为新的主节点，并且将其余的从节点指向新的主节点，这样人工干预就能够免了。
  • 配置提供者：在Redis Sentinel模式下，客户端利用在初始化时连贯的是Sentinel节点汇合，从中获取主节点的信息。

哨兵的原理

1、每个Sentinel节点都须要定期执行以下工作：每个Sentinel以每秒一次的频率，向它所知的主服务器、从服务器以及其余的Sentinel实例发送一个PING命令。（如上图）

2、如果一个实例间隔最初一次无效回复PING命令的工夫超过down-after-milliseconds所指定的值，那么这个实例会被Sentinel标记为主观下线。（如上图）

3、如果一个主服务器被标记为主观下线，那么正在监督这个服务器的所有Sentinel节点，要以每秒一次的频率确认主服务器确实进入了主观下线状态。

4、如果一个主服务器被标记为主观下线，并且有足够数量的Sentinel（至多要达到配置文件指定的数量）在指定的工夫范畴内批准这一判断，那么这个主服务器被标记为主观下线。

5、个别状况下，每个Sentinel会以每10秒一次的频率向它已知的所有主服务器和从服务器发送INFO命令，当一个主服务器被标记为主观下线时，Sentinel向下线主服务器的所有从服务器发送INFO命令的频率，会从10秒一次改为每秒一次。

6、Sentinel和其余Sentinel协商主观下线的主节点的状态，如果处于SDOWN状态，则投票主动选出新的主节点，将残余从节点指向新的主节点进行数据复制。

7、当没有足够数量的Sentinel批准主服务器下线时，主服务器的主观下线状态就会被移除。当主服务器从新向Sentinel的PING命令返回无效回复时，主服务器的主观下线状态就会被移除。

点击关注，第一工夫理解华为云陈腐技术~