摘要： Redis在主从模式下需要考虑很多问题。 这里写了几个关于多服务器上Redis的问题分析和总结。 Redis单节点存在单点故障问题。 为了解决单点问题，通常需要在Redis中配置从节点，并使用哨兵拦截主节点的生存状态。 如果主节点锁定，从节点可以继续提供缓存功能。 主从配置与哨兵模式相结合可以解决单点故障问题，提高redis的可用性。 从节点只提供读取，主节点提供写入。 在读写较少的情况下，可以通过在主节点上配置多个从节点来提高响应效率。
主从复制过程：从节点执行slaveof[masterIP][masterPort]，保存主节点的信息，从主节点中的计时器任务中发现主节点的信息，并与主节点进行套接字主节点恢复为大山水，双方可以相互通信连接后，主节点将所有数据发送到从节点(然后主节点继续向从节点发送写命令，保证从节点的数据完整性)。 在Redis的数据同步过程：redis2.8之前使用sync[runId][offset]同步命令，在redis2.8之后使用psync[runId][offset]命令。
两者之间的区别在于，sync命令只支持全局复制过程，而psync支持全局和部分复制。
在介绍同步之前，我先介绍一些概念。
runId：每个redis节点启动时都会生成唯一的uuid，并且每次redis重新启动时runId都会发生变化。
offset：主节点和从节点分别维护自己的主从复制偏移offset，如果主节点有写入命令，则offset=offset命令的字节长度。 从节点在接收到主节点发送的命令后，增加自己的offset，并将自己的offset发送给主节点。 因此，主节点同时保存自身的offset和从节点的offset，并通过比较offset来判断主从节点的数据是否一致。
存储在repl_backlog_size：主节点上的固定长度先进先出队列。 默认大小为1MB。
当主节点向从节点发送数据时，主节点会执行一些写入操作，此时的数据将存储在复制缓冲区中。 当从节点的主数据同步完成后，主节点继续将缓冲区中的数据发送到从节点，用于部分复制。 当主节点响应写入命令时，它不仅将名称发送到从节点，还将写入复制积压缓冲区，用于修复复制命令中丢失的数据。
以上是psync的执行过程。
从节点发送psync[runId][offset]命令时，主节点有三个响应：
FULLRESYNC :首次连接并进行全局复制CONTINUE :不支持进行部分复制的err:psync命令，进行全局复制和部分复制的过程
上面是全量复印的流程。 主要有以下步骤。
是否要从节点发送p同步？ -1命令(因为初次发送，不知道主节点的runId，所以？因为是第一次复制，所以offset=-1 )。 主节点发现从节点是第一个复制，并返回完整resync { run id } { offset }。 runId是主节点的runId，offset是主节点的当前offset。 从节点接收主信息后，保存到info。 主节点在发送FULLRESYNC后，启动bgsave命令并生成RDB文件(数据持久化)。 主节点将RDB文件发送到从节点。 在从节点加载数据并完成之前，主节点的写入命令将放在缓冲区中。 从节点上清理自己的数据库数据。 从节点加载RDB文件，并将数据保存到自己的数据库中。 -如果从节点启用了AOF，则从节点异步重写AOF文件。 关于部分复制，有以下说明。 部分复制主要是Redis对全局复制开销采取的优化措施，通过使用psync[runId][offset]命令实现。 如果从节点正在复制主节点时发生网络闪烁或命令丢失等异常情况，则从节点请求主节点重新发出丢失的命令数据，主节点的回复缓冲区重新发行的这部分数据一般远远小于全部数据。 主节点在主从连接断开时也会响应命令，但无法将复制连接断开命令发送到从节点。 但是，主节点中的复制积压缓冲区可以保留最近的写入命令数据。 主从连接恢复后，从节点保存了以前自己复制的偏移和主节点的执行ID。 因此，将它们作为psync参数发送到主节点，请求部分复制。 主节点在接收到psync命令后，首先检查参数runId是否与自身一致，如果一致，则表示以前复制的是当前主节点； 接着，基于参数offset查找复制积压缓冲器，如果存在offset以后的数据，则向从节点发送COUTINUE命令，表示可以进行部分复制。 由于缓冲区大小固定，在发生缓冲区溢出时进行全量复制。 主节点根据偏移将副本积压缓冲区中的数据发送到从节点，以确保主从副本处于正常状态。 在Redis主从复制中，当主节点停机时，从节点将升级为主节点，需要更改APP应用程序端的主节点地址，并指示所有从节点复制新的主节点主节点的写入能力受独立的限制。 主节点的存储能力受独立的限制。 本机复制的缺点在早期版本中也很明显，例如，在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命令返回有效回复时，主服务器的主观下线状态就会被移除。
点击关注，第一时间了解华为云新鲜技术~