Redis的哨兵集群(一主两从三哨兵、部署教程和知识总结)_redis哨兵集群部署

自己写的笔记，收藏就完事了，以后实战或者面试肯定用得到，hhh

Ps: 如果对Redis搭建不熟悉,可以看我之前的一个博客: Redis的单机部署(Linux环境)-CSDN博客

一、哨兵机制

  1.1 主要功能:

1. 故障检测：哨兵定期检查主服务器（master）和从服务器（slaves）是否正常工作。它通过发送命令并等待响应来检测服务器是否在线且运行正常。如果某个服务器未能正确响应，哨兵会认为该服务器是处于下线状态。

2. 自动故障转移：如果主服务器发生故障，哨兵会自动进行故障转移操作。它会从现有的从服务器中选举出一个新的主服务器，并指示其他从服务器改变同步方向，同步新的主服务器的数据。这样能确保系统的快速恢复和数据的最大程度保存。

3. 配置提供者：哨兵还充当配置提供者的角色。客户端可以询问哨兵当前哪个是主服务器，从而连接到正确的服务器进行读写操作。

4. 通知：哨兵可以在检测到故障或其他重要事件时通过API向管理员或其他应用发送通知。

   1.2 哨兵的工作原理：

1. 监控：哨兵会监控所有的 Redis 主从服务器实例，检查它们的健康状态。
2. 选举：如果主服务器无法响应，哨兵之间会进行选举，决定哪一个哨兵负责执行自动故障转移。
3. 故障转移：负责故障转移的哨兵会自动选择一个从服务器，提升为新的主服务器，并配置其他从服务器重新指向这个新的主服务器。

二、准备部署环境

      2.1 配置信息

Ps:

1、采用一主两从三哨兵方案部署, 因虚拟机资源有限3台哨兵搭建和Redis搭再同一台机器上, 建议生产环境使用不同的机器部署, 防止单点故障问题。

2、通常建议至少部署三个哨兵实例，这样即使一个哨兵实例发生故障，其他两个可以继续进行故障检测和转移决策。

三、Redis主从集群搭建

 Ps:  再搭建哨兵集群之前,需要先部署一个主从的一个Redis集群,下面是部署一主两从的一个集群搭建过程。

  3.1 在三台机器上分配安装Redis服务

    这里就简单说一下过程, 详细安装方式可以参照: Redis的单机部署(Linux环境)-CSDN博客

    1.下载Redis的安装包

    2.解压安装包并进行make编译

    3.对配置文件redis.conf 进行修改

    4.启动Redis服务,指定配置文件

  3.2 集群的相关配置修改

      1.首先对主节点的配置文件进行修改

#设置主节点访问密码
#命令解释:把 masterauth Test2024 添加在 bind ip 内容的下两行 
sed -i "/^bind .*/a\\ \n\\masterauth Test2024" redis_conf

         (1). 这里解释一下为啥主节点自己也要配置密码呢? 因为当主节点发生故障后,哨兵把其他机器选举为主节点, 该机器恢复正常后要加入集群就需要该密码配置了. 其次建议Redis的密码都设置一样,避免其他的错误出现。

     2.从节点的配置文件修改

      下面设置从节点Redis配置文件, 登录到192.168.195.60和192.168.195.61这两台机器上并修改

他们的配置文件内容。

# 设置主节点IP地址,并且保证他们之间的网络通畅
sed -i "/^bind .*/a\\ \n\\slaveof 192.168.195.59 6379" redis_conf
 
#设置主节点Redis的访问密码
sed -i "/^bind .*/a\\ \n\\masterauth Test2024" redis_conf

  PS: 必须要保证几台机器的网络畅通,并且可以访问到彼此的Redis服务。

  3.3. 完成上述修配置文件修改后, 对Redis进行重启

    PS: 当然按先主后从顺序进行重启

# 按先主后从顺序进行重启, 三台机器重启完成后,使用客户端工具redis-cli 登录到Redis
 
#cd 到你的Redis目录下,登录Redis
./src/redis-cli -p 6379 -a Test2024 

  3.4 使用 info Replication 命令查看Redis的信息,

     1.可以看到已经有两个节点连接上了该主节点

     2.可以在主节点新增一个key-value  

#设置key-value
set name zhangsan
 
#获取key-value 在从节点机器登录上Redis查看数据有没有同步过来
get name

  以上就基本完成了一主两从的环境搭建,可以开始搭建哨兵来监控主节点了

四、哨兵集群搭建

  4.1 修改哨兵的配置文件

    对三台机器上的哨兵配置文件进行修改,内容如下

#cd 至redis的安装目录
cd /usr/local/redis-6.0.10
 
#创建哨兵的工作目录
mkdir -p /usr/local/redis-6.0.10/redis-sentinel-working
 
#可自行vi命令编辑 sentinel_conf 
 
#配置哨兵的工作目录
sed -i "s/^dir .*/dir /usr/local/redis-6.0.10/redis-sentinel-working /"  sentinel_conf
 
#配置哨兵的日志文件
sed -i "s/^logfile .*/logfile  /usr/local/redis-6.0.10/redis-sentinel.log /" sentinel_conf
 
#配置哨兵的端口号 配置文件中默认就是26379 
sed -i "s/^port .*/port 26379 /" sentinel_conf
 
#设置主节点ip 端口 mymaster 192.168.195.59 6379 2 
sed -i "s/^sentinel monitor .*/sentinel monitor mymaster 192.168.195.59 6379  2 /" sentinel_conf
 
#设置redis访问密码
sed -i "/^sentinel monitor .*/a\\ \n\\sentinel auth-pass mymaster Test2024" sentinel_conf

PS:  解释一下sentinel monitor 这个参数

    1. mymaster 是主节点的名称, 我这里是采用Redis推荐的默认值, 如果修改的话, 要注意其他位置同步修改。

    2. ip port  这个就是主节点的Redis的IP和端口。

    3.结尾是一个2表示至少需要有 2 个哨兵同意主节点已经下线，才会启动自动故障转移过程。要根据哨兵数量来设置,默认值是2,过少可能会误判,过高则可能在部分哨兵失效时无法执行故障转移。一般推荐的设置是部署哨兵总数的一半加一，以确保故障转移的决策得到多数哨兵的支持。

4.2 启动哨兵服务

     当三台机器的哨兵配置完成后,就可以启动哨兵来监控我们的主从集群了

    1.第一种方式使用命令去启动哨兵

#切换至redis目录
ca /usr/local/redis-6.0.10
 
#自行启动时如果没用修改后台运行的那个参数daemonize 可以像redis一样启动时指定
./src/redis-sentinel ./redis.conf --daemonize yes
 
#关闭哨兵服务, 这里是使用redis客户端工具进行关闭 需要指定关闭的端口号,不然默认关闭Redis服务
./src/redis-cli -p 26379 shutdown

 2.第二种方式把哨兵服务交给系统服务去管理(原理和之前Redis一样)

#1.在Systemd服务单元文件中设置ExecStart
 
cat <<EOF | sudo tee /etc/systemd/system/redis-sentinel.service > /dev/null
[Unit]
Description=redis-sentinel
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/redis-6.0.10/src/redis-sentinel /usr/local/redis-6.0.10/sentinel.conf
ExecStop=/usr/local/redis-6.0.10/src/redis-cli -p 26379 shutdown
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
EOF
 
#2.重新加载Systemd管理的所有服务
sudo systemctl daemon-reload
 
#3.启用Redis服务
systemctl enable redis-sentinel.service
 
#4.启动Redis服务
systemctl start redis-sentinel
 
#5.查看哨兵运行信息
systemctl status redis-sentinel

使用客户端工具登录或直接查看哨兵的信息

#切换目录
cd /usr/local/redis-6.0.10
 
#登录到哨兵 #在执行命令: info Sentinel 查看哨兵信息
./src/redis-cli -p 26379
 
#或者直接查看信息命令
./src/redis-cli -p 26379 info Sentinel
 

可以看出哨兵集群的个数为1了.

同理把三台机器的哨兵服务都启动成功就ok了, 以上基本就搭建完了哨兵集群了

PS: 这里再学习的时候遇到一个坑,就是哨兵节点都配置并启动了,但是查询哨兵信息仍然只有一个，排查了很久才解决，后续再分享一下这个坑吧。

Redis的哨兵集群（Sentinel info 中的数量与实际数量不一致）_info sentinel 参数slaves只有一个-CSDN博客

下面是完成了哨兵集群搭建的结果

五、验证哨兵的选举机制

   5.1 模拟Master节点宕机

1. 使用系统服务关闭 192.168.195.59 机器上的Redis服务

#这样关闭redis服务,即使设置了保活Redis 也不会自动重启服务
systemctl stop redis

2.查看哨兵日志, 开始选举新的节点了

3.查看192.168.195.60机器的redis信息, 发现192.168.195.61机器被选举为新的Master

4.再次把原主节点(192.168.195.59)的Redis启动, 查看哨兵日志。

发现这台机器也重新加入集群了, 但是变成了slave的角色了。(这里重新上线需要在配置文件中加上主节点的密码, 之前搭建主从的时候, 就提前把所有节点都配置上masterauth就好了)

5.2 故障转移成功后通知节点更新配置文件

  1.上面模拟了Master宕机情况,查看Redis的配置文件

  这台 195.168.195.59 机器原先为主节点, 当重新加入集群时候,配置问价末尾自动追加了主节点的IP信息

 

另外两台机器的配置文件也都自动更新主节点信息。

  2.哨兵的配置文件也做了自动更新

GPT3.5的回答如下:

六、总结 

    6.1 优点

• 自动故障转移：   

              Sentinel 能自动检测主节点和从节点的故障，并自动将从节点升级为新的主节点，从而保                证服务的连续性和可用性。

• 分布式监控：

  • Sentinel 可以以分布式方式运行，多个 Sentinel 实例之间会相互通信，共同决定是否需要进行故障转移。这增强了系统的健壮性和故障容忍能力。

• 服务发现：

  • Sentinel 也承担配置提供者的角色，客户端可以查询 Sentinel 获取当前的主节点地址，这使得客户端总是连接到正确的主节点。

• 可配置性：

  • Sentinel 提供了多种配置选项，允许管理员根据具体需求调整故障检测的灵敏度、故障转移的行为等。

• 通知：

  • Sentinel 支持通过各种方式通知管理员，例如发送邮件、执行脚本等，当监测到故障或者其他重要事件时。

   6.2 缺点

• 资源使用：

  • 每个 Sentinel 实例也会占用系统资源，包括 CPU 和内存，尤其是在大型集群中。

• 网络依赖性：

  • Sentinel 的效果很大程度上依赖于网络的可靠性。网络分区或是延迟高的情况可能会导致误判或故障转移延迟。

• 冷启动问题：

  • 如果所有 Redis 节点同时宕机，Sentinel 系统无法自动恢复，需要手动干预来重新设置主节点和从节点。

• 数据丢失风险：

  • 在发生故障转移时，如果还有未同步到从节点的数据，那么这部分数据可能会丢失。这是因为 Redis 使用异步复制。
•  写操作的局限性:

    1. 单点瓶颈：

•  在一主多从架构中，所有写操作都必须由主节点处理。这意味着主节点的处理能力和资源（CPU、内存、网络带宽）将直接限制系统的写入吞吐量。

   2. 数据同步延迟：

• 尽管从节点可以提供读扩展性，但它们依赖于与主节点的数据同步。在高写负载情况下，数据复制到从节点可能会经历延迟，这影响了数据的最终一致性。

   3. 故障风险：

• 如果主节点出现故障，整个系统的写能力会丧失直到故障转移完成并且一个从节点被提升为新的主节点。这个过程可能会导致服务中断。

PS: 上面有一个坑下次分享一下吧, 关于哨兵配置文件的。

PS:  后续继续分享一些有用的知识, 关注点赞收藏咯。