Redis6高可用之主从复制+Sentinel哨兵监控

主从复制的介绍

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者为主节点（master），后者成为从节点（slave）；数据的复制都是单向的，只能由主节点到从节点。默认情况下，每台Redis服务器都是一个主节点，且一个主节点可以有多个从节点（或者没有从节点），但一个从节点只能有一个主节点。

使用主从复制的好处：读写分离，能够扩展主节点的读能力，给主节点分担压力。容灾恢复，一旦主节点宕机，可以在从节点作为主节点的备份随时可以顶上来。

架构介绍

从节点复制了主节点的数据，复制之后我们就可以做一个读写分离。如果是单节点的话，应用程序的请求都集中在主节点，但有了从节点之后可以承担部分的读压力。主节点就可以做读写操作，而从节点只做读操作。这样便给主节点分担压力了。

Redis主从复制，一主二从架构环境准备

说了那么多概念咱们就开始动手部署Redis的主从复制架构吧，这次我们部署的是一主二从的架构。

首先创建一个主节点，在data/redis/master/data目录下touch一个redis.conf文件，编辑redis.conf文件

接着创建从节点1，在data/redis/slave1/data目录下建redis.conf

创建从节点2，在data/redis/slave2/data目录下建redis.conf

注意：防火墙记得关闭，阿里云服务器记得开放网络安全组。

创建好后就开始启动已经配置好的节点

启动方式：

使用info replication可以查看当前节点的状态

主从复制和读写验证

Redis6主从架构-复制读写分离原理解析

主从复制分为两种：一种是主从刚开始连接的时候，进行全量同步；另一种是全同步结束后，进行增量同步。

全量复制：master服务器会开启一个后台的进程用于将Redis的数据生成一个rdb文件，主服务器会缓存所有接受到的来自客户端的写命令，当后台保存进程后，会将rdb文件传递给slave服务器，这时候slave服务器就有了master服务器的数据了。在此之后，master服务器会将在此期间把缓存过来的命令通过redis传输协议发送给slave服务器，然后slave服务器再将这些命令依次用于自己本地上，最终达到数据的一致性

增量复制：主节点会有不断的命令写进来，slave完成初始化后开始工作时主服务器发送写的操作同步到服务器的过程就叫增量复制。增量复制是服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接受并执行收到的写命令。

主从复制有何特点：

主从复制对于主/从 服务器来说都是非阻塞的，所有在同步数据期间都可以正常处理外界的请求，一个主节点可以包含有多个从节点，每个从节点可以接受来自其他从节点的连接。从节点不会让key过期，而是在主节点的key过期删除后，发送删除命令给从节点进行删除。

加速复制：在节点完成重新同步的时候需要在磁盘上创建一个RDB文件，然后加载这个文件来为从服务器发送数据，但如果磁盘的速率比较低呢？这就会导致主节点与从节点的数据不一致。在新版的Redis中，支持无磁盘的复制，直接将RBD文件通过网络发送的形式给从服务器，不在使用磁盘作为中间件。

如果主从连接断开的话，重新连接后可以从中断的地方继续进行复制，而不用重新同步。在2.8版本后，重新同步的这个新特性使用PSYNC命令，而旧的使用SYNC命令

什么是Sentinel哨兵监控

前面搭建了主从复制，也了解到当主服务器宕机后，需要手动的把一台从服务器切换成主服务器。是不是感觉很麻烦？没错这样的话不仅费人工，还会造成一段时间内服务不可用，这显然是不可行的。所有，Redis就有了哨兵模式。Redis提供了哨兵命令，它是一个独立的进程哨兵通过发送命令给多个节点，并让Redis的服务器响应，从而来监控Redis实例的运行情况。当哨兵检查到主节点宕机了，会自动将从节点切换成主节点，并通知其他的从服务器修改配置文件切换主机。

Sentinel有三大任务

任务一：监控，Sentinel不会断地检查你的主服务器和从服务器是否工作正常。

任务二：提醒，当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他的应用程序来发送通知，提醒发现故障了。

任务三：自动故障转移，上面我们提到需要人工进行故障转移，而使用Sentinel就可以实现自动转移了。当一个主服务器不能正常工作的时候，Sentinel会开始自动故障转移操作，它会将故障的主服务器下的其中一个从服务器升级成主服务器，并让这个故障的主服务器下的所有从服务器改为复制新的主服务器。当客户端连接失败主服务器时，也会向客户端返回一个新的服务器地址，使得可以使用新的服务器地址来代连接失败的主服务器。

思考一下，这样是否会出现问题呢？一个哨兵进程对Redis服务器进行监控，如果因为网络问题呢，哨兵得不到服务器的响应了，这时你就会想那设置多个哨兵同时进行监控不就好了。但是多个哨兵监控的话，会形成多哨兵模式，接下来讲解一下多哨兵模式。

多哨兵模式下线名称介绍

主观下线（Subjectively Down，简称SDOWN）

是单个Sentinel实例对服务器做出下线的判断，比如上面所说的网络问题接受不到通知等。在一个服务器没有在down-after-milliseconds选项的指定时间内给Sentinel进行响应，那么Sentinel就会认为主管服务器已经下线了（理解成故障也可以）。

客观下线（Objectively Down，简称ODOWN）

指的多个Sentinel在对同一个服务器做出SDOWN判断，并且哨兵通过SENTINEL is-master-down-by-addr命令进行相互交流之后，得出服务器是否是下线。

客观下线这种条件只适用于主服务器

仲裁quornm

当在Sentinel给定的时间范围内，从其他Sentinel接受到了足够数量的主服务器下线报告，那么Sentinel就会将主服务器的状态从主动下线改成客观下线。这个足够数量就是配置文件中的值，一般设置为Sentinel的个数一般加1，比如4个Sentinel就设置成3个。

Sentinel哨兵搭建环境准备

核心流程：设置每秒ping,服务器超过指定时间不响应，那么就任务该服务器是主观下线的。多个哨兵任务主服务器是下线的话，那么就认为是客观下线，然后进行投票，在该主服务器下选择从服务器变成主服务器。如果没有足够数量同意这个主服务器下线，那么该服务器的状态就会被移除。

环境准备：

第一步：配置三个哨兵，每个哨兵的配置都是一样的。

第二步：启动的先后顺序为主服务器->从服务器->哨兵。

第三部：哨兵的端口号是：26379（记得要开放）

在redis/conf目录下创建三个哨兵

sentinel-1.conf

sentinel-2.conf

sentinel-3.conf

记得创建目录/var/log/redis文件夹，主要是用于存放哨兵的log日志文件

启动哨兵（启动哨兵失败需要开放网络安全组的端口）

优点：主从可以自动切换，可用性更高了。

缺点：主节点的写能力和存储能力受限

简单分析下日志

1.老大掉线了

2.疯狂向老大发送询问（老大，你挂掉没？没回答，就应该是挂掉了，这时哨兵就辅助从节点变成老大）

3.自己就成为了老大MASTER MODE enabled

4.跟其他小弟进行数据请求（前老大都挂了，你们还不跟我？）

5.接着就是新的主从建立好了

SpringBoot整合Redis主从+Sentinel哨兵

在上面已经清楚了解到如何在Redis中使用哨兵，并且如何搭建哨兵环境。接下来开始使用SpringBoot+Sentinel哨兵的整合。

首先在application.yml中配置中注释掉Redis的host与port

在添加新的配置（哨兵相关配置）

这样就可以在项目中配置好Redis的哨兵相关配置了，哨兵在Redis里是使用得比较频繁的。