Redis的高可用性

前言

    对于Redis的知识的话我在前两篇文章当中已经说明了,那么这篇文章的话我们就会在前两篇的基础之上进行一个知识的提高,让我们的思考的高度更升一层楼,加油加油

Redis的高可用性:

  我们在前面说的知识其实都是在一台机器上实现的,可是我们就要想一个问题那么就是在我们真实的环境中,如果只有一台机器的话那么假如这个机器发生故障了那么就会导致我们整个的系统无法正常使用了,这个肯定是不行的所以我们肯定是增强系统的高可用性那么肯定是要进行集群部署

集群：

  进行主从复制其实也就是将主机器的数据同步到其他的从服务器当中,这样的话即使主机器出现故障的话那么其他的机器也会进行保障

 但是这个就是也会产生一个问题,就是要保证这些服务的的数据保持一致性这个就是一个让人十分头疼的问题,所以Redis就给我们提供了主从复制模式来保证数据一致性

主从复制:

  其实这个和Mysql的读写分离是源自同一个思想的,也就是说主机器负责客户端的写请求然后其他的机器共同分担客户端的所有的读请求,这样的话就让主服务器的压力比较小

同步的过程:

 第一次同步：主要就是由三个步骤完成的

   第一步:主服务器和从服务器之间建立连接，这个主要就是从机器发送psync命令,这个里面就是包括的就是主服务器的ID以及复制的进度offset，那么主服务器接收到之后就会发送fullresync给从服务器,这个就是告诉从服务器将进行全量复制(就是将所有的数据都会同步给从服务器)

   第二步： 主服务器将数据同步给从服务器,这个肯定是生成RDB文件(通过创建子线程),然后将这个文件发送给从服务器但是这个时候又可能由新的写操作命令执行完成那么这个时候将这个命令写入到缓冲区(replicationbuffer)进行保存

   第三步: 主服务器将写命令的数据传输给从服务器,这个时候就是会将写入到缓冲区中的写操作命令同步到从服务器中保证数据的一致性,前提: 就是说从服务器接收到主服务器的RDB文件之后将自己所有的数据进行删除然后发送确认消息给主服务器

 增量复制(这个就是已经同步过一次)： 主从同步过一次之后如果再写命令同步的时候网络出现了问题,那么这个时候命令肯定时不能进行命令传播,那么客户端就会读取旧的数据如果网络恢复正常的话那么如果进行一次全量复制的话那么成本就会太大所以就有了增量复制

具体的实现的话也就是三步走战略：

第一步: 依然是从服务器向主服务器发送psync命令(这个里面就会包括复制offset偏移量)重新建立连接

第二步: 主服务器接收到从服务器的命令请求之后还会发送Continue的命令告诉从服务器进行增量复制进行数据的同步

第三步: 这个时候主服务器就会将断线区间的新的已经执行完成的命令发送给从服务器 这个就是会产生一个问题就是 主服务器怎么知道将哪些命令发送给从服务器 答案： 就是说通过偏移量获得上次复制的位置是在哪里然后就会从缓存区中获得新的写的命令,除此以外主服务器还会记录自己的偏移量(这个也是会在一个缓存区中), 这个就是重新建立连接之后如果发现二者偏移量差距太大的话那么就会进行全量复制的方式

     哨兵集群：

         先不说专业的知识这个就是说为每一个节点添加一个哨兵,这个哨兵肯定第一个想到的是监控的作用,如果能这么想的话那么就对了,这个就是其中一个作用 它的其他的作用就是选主以及通知因为如果我们的主节点出现故障的话那么肯定会启动其他的从节点这个时候这个从节点就是会升级为主节点,那么其他的从节点的配置的信息肯定是要进行修改

监控:  这个就要就是说每隔一段的时间然后就是看节点是否会进行回应,如果过一段时间不正常的话那么就会对这个主节点判定为主观下线但是这个肯定是不行的会出现误判因为其他哨兵没有进行判断所以这个肯定是其他哨兵也会发送请求然后进行判断(客观判断), 如果超过一半判断这个节点下线的话那么这个节点就是下线

选主:  如果判断的是主节点下线的话那么就会从其他的节点选择一个新的主节点,这个肯定就是由全部的哨兵进行决定的,但是肯定是其中一个的哨兵进行,所以哨兵节点之间就是会进行Raft算法进行投票选出那个领头的,然后这个领头的就会从其他的节点根据 优先级 复制进度 等选择出一个新的主节点

通知: 选择一个新的主节点之后那么肯定是通知其他的节点以及服务主节点已经发生变化要对原来的信息进行一次更新 但是这个就是会产生一个问题:如果旧的主节点重新建立连接之后应该怎么办解决方案:就是将这个旧的主节点变为新的主节点的从节点也就是进行全量复制以及配置信息更新