Redis哨兵高可用性(包含创建sentinel节点以及配置文件)_哨兵节点检测了所有的哨兵节点-CSDN博客

本文链接：https://blog.csdn.net/qq_51959224/article/details/124487612

Redis哨兵 (Redis Sentinel)

声明:本次笔记全本人手写,如果想看redis数据节点的配置文件和sentinel节点的配置文件请直接跳到9.2.2和9.2.3

22/4/29/lsj

本次笔记主要了解Redis Sentinel,实现Redis主从复制高可用,以及实现原理

Redis Sentinel 的概念
Redis Sentinel 的安装部署
Redis Sentinel 的API详解

9.1基本概念

9.1.1 主从复制的问题

Redis 的主从复制可以将主节点的数据同步给从节点,实现主从一致,这样从节点起到两个作用:

作为主节点的一个备份,主节点出现故障不可达的时候,可以作为主节点的一个备份,并且保证数据尽量不丢失。
从节点可以扩展主节点的读能力,进行读写分离,一旦主节点撑不住大量的并发读操作,那么从节点可以分担读压力。

但是主从复制也有几个问题:

一旦主节点出现故障,需要手动将一个从节点升为主节点(slave no one),同时需要修改应用方的主节点地址(改为之前的从节点地址),还需要命令其他从节点去复制新的主节点,整个过程都需要人工的干预
主节点的写能力受到单机的限制
主节点的存储能力受到单机的限制其中第一个问题是高可用问题,用redis Sentinel可以解决,下面两个问题是分布式的问题,将在后续笔记中展现。

9.1.2 高可用

在Redis的主从复制下,一旦主节点出现了故障不可达的情况,需要人工进行干预,把从节点升级为主节点,其他从接待你复制新的主节点,还要干预应用方,这样是不能接受的,会造成一些数据的丢失。

接下来会介绍主从复制模式下,主节点出现故障是如何进行故障转移的 :

主节点发生故障之后,客户端连接失败,两个从节点与主节点连接失败造成连接中断
主节点无法正常启动,需要选择一个从节点成为一个新的主节点(执行命令slave no one)
原来的从节点成为新的主节点之后通知应用方主节点信息然后重启
客户端命令其他从节点复制新的主节点
原来的主节点恢复之后复制新的主节点

上述的这些流程如果是人工干预那么就不是高可用的,整个故障转移过程有些公司已经自动化了,但也要考虑三个问题:

判断节点不可达机制是否健全
如果有多个从节点,那么怎样保证只有一个从节点晋升成主节点
通知客户端新的主节点机制是否足够健壮

以上的所有问题都可以用Redis Sentinel实现(主从复制故障转移的高可用问题)

9.1.3 Redis Sentinel 的高可用性

Redis Sentinel是一个分布式架构(Redis数据节点,Sentinel节点集合,客户端分布在多个物理节点的架构),其中包含多个Redis Sentinel节点和Redis数据节点

每个Sentinel节点都会对Redis数据节点和其他Sentinel节点进行监控,当发现其他节点不可达的时候,会对节点做一个下线的标志
如果被标志的是主节点,他会和其他的Sentinel节点协商,大多数Sentinel节点认为主节点不可达的时候,会推选出一个Sentinel节点完成主从故障的功能
这一套都是自动的,完成后会通知应用方,这实现了高可用性

Redis主从复制模式和Redis Sentinel架构的区别(如图):

结构上可以知道redis Sentinel会定期对所有节点进行监控和进行故障转移

下面进行Redis Sentinel的例子进行故障转移说明(一共四步,第四步是Redis Sentinel领导者节点执行故障转移的步骤):

主节点出现故障,从节点与主节点失去连接
Redis Sentinel通过检测,检测到主节点故障
Redis Sentinel推选出一个Sentinel节点进行执行故障转移
Redis Sentinel进行故障转移
- 从节点执行slave no one
- 从节点复制新的节点
- Sentinel通知客户端
- 原来主节点复制新的主节点如图:

故障转移后的拓扑结构图如下:

通过Redis Sentinel故障转移可以得知Redis Sentinel具有以下几个功能:

监控
通知
主节点故障转移
配置提供者

Redis Sentinel包含了若干个Sentinel节点,这样做的好处如下:

9.2 安装和部署

9.1讲解了Redis Sentinel基本架构,接下来讲解一下安装和部署以及使用

9.2.1 部署拓扑结构

9.2.2 部署Redis数据节点

首先配置三个redis.conf,分别是:

redis-6379.conf

主节点重点配置文件:
port:6379
daemoize yes   #默认挂在服务器上
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/root/redis-5.0.0/data"

#启动主节点 redis-server redis-6379.conf
#连接主节点 redis-cli -h 127.0.0.1 -p 6379

redis-6380.conf

   从节点1重点配置文件:
    port:6380
    daemoize yes   #默认挂在服务器上
    logfile "6380.log"
    dbfilename "dump-6380.rdb"
    dir "/root/redis-5.0.0/data"
    slaveof 127.0.0.1 6379   #默认启动自动复制6379节点
    
    #启动从节点1 redis-server redis-6380.conf
    #连接从节点1 redis-cli -h 127.0.0.1 -p 6380

redis-6381.conf

   从节点2重点配置文件:
    port:6381
    daemoize yes   #默认挂在服务器上
    logfile "6381.log"
    dbfilename "dump-6381.rdb"
    dir "/root/redis-5.0.0/data"
    slaveof 127.0.0.1 6379   #默认启动自动复制6379节点
    
    #启动从节点1 redis-server redis-6381.conf
    #连接从节点2 redis-cli -h 127.0.0.1 -p 6381

重点避坑:如果主节点设置密码了,那么从节点的conf里面的masterauth一定要设置的主节点一模一样,如果主节点没有设置密码,那么从节点的masterauth要注释掉,否则会链接失败,所以有密码的尽量全设置成一样,主从节点的auth都设置一样,主从节点的masterauth也都设置一样,这样主节点宕机之后,从节点成为新的主节点,其他从节点复制新的主节点不会因为密码问题连接不上

9.2.3 部署Sentinel节点

三个文件都一样,只不过端口不一样,所以这里就配置了一个

redis-sentinel-26379.conf

主节点重点配置文件:
port:26379
daemoize yes   #默认挂在服务器上
logfile "26379.log"
dir "/root/redis-5.0.0/data"

#启动哨兵方式一: redis-server redis-sentinel-26379.conf --sentinel
#启动哨兵方式二: redis-sentinel redis-sentinel-26379.conf
#连接哨兵节点 redis-cli -h 127.0.0.1 -p 26379

连接成功之后的info sentinel命令,可以看出当前这个哨兵节点检测了所有的哨兵节点,检测了两个从节点

至此,Redis Sentinel都搭建起来了,下面这个图是最终的拓展图:

9.2.4看另一章笔记

9.2.5 部署的建议和技巧

以上的部署方法已经掌握了,那么在实际环境下的部署技巧,本小节就来总结一下

在生产环境中Redis Sentinel接待你不应该部署在一台物理机上面,应该部署在多台物理机上,同一台物理机可能会故障,那么这台物理机上的所有虚拟机都将会受到影响,影响Sentnel的高可用性
部署至少三个且基数个数的Sentinel节点
- 3个以上是通过添加Sentinel节点来提高对于故障判断的准确性,欣慰领导者选举至少需要一半+1个节点,奇数可以满足在这个条件下节省一个节点
只有一套Sentinel还是多套Sentinel,每个主节点配置一套Sentinel,两种各有各的优势