自己写的笔记，收藏就完事了，以后实战或者口试肯定用得到，hhh
Ps: 如果对Redis搭建不熟悉,可以看我之前的一个博客: Redis的单机部署(Linux环境)-CSDN博客
一、哨兵机制
1.1 重要功能:
- 故障检测：哨兵定期检查主服务器（master）和从服务器（slaves）是否正常工作。它通过发送下令并等待相应来检测服务器是否在线且运行正常。如果某个服务器未能精确相应，哨兵会认为该服务器是处于下线状态。
- 主动故障转移：如果主服务器发生故障，哨兵会主动进行故障转移操作。它会从现有的从服务器中选举出一个新的主服务器，并指示其他从服务器改变同步方向，同步新的主服务器的数据。这样能确保体系的快速规复和数据的最大程度生存。
- 配置提供者：哨兵还充当配置提供者的脚色。客户端可以扣问哨兵当前哪个是主服务器，从而连接到精确的服务器进行读写操作。
- 关照：哨兵可以在检测到故障或其他重要事件时通过API向管理员或其他应用发送关照。
1.2 哨兵的工作原理：
- 监控：哨兵会监控所有的 Redis 主从服务器实例，检查它们的康健状态。
- 选举：如果主服务器无法相应，哨兵之间会进行选举，决定哪一个哨兵负责执行主动故障转移。
- 故障转移：负责故障转移的哨兵会主动选择一个从服务器，提拔为新的主服务器，并配置其他从服务器重新指向这个新的主服务器。
二、预备部署环境
2.1 配置信息
| 服务类型 | IP地址 | 端口 | | Redis (Master) | 192.168.195.59 | 6379 (默认) | | Redis (Slave) | 192.168.195.60 | 6379 | | Redis (Slave) | 192.168.195.61 | 6379 | | Sentinel | 192.168.195.59 | 26379 (默认) | | Sentinel | 192.168.195.60 | 26379 | | Sentinel | 192.168.195.61 | 26379 |
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
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
3.3. 完成上述修配置文件修改后, 对Redis进行重启
PS: 当然按先主后从顺序进行重启
- # 按先主后从顺序进行重启, 三台机器重启完成后,使用客户端工具redis-cli 登录到Redis
- #cd 到你的Redis目录下,登录Redis
- ./src/redis-cli -p 6379 -a Test2024
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
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
同理把三台机器的哨兵服务都启动成功就ok了, 以上根本就搭建完了哨兵集群了
PS: 这里再学习的时候遇到一个坑,就是哨兵节点都配置并启动了,但是查询哨兵信息仍旧只有一个，排查了好久才解决，后续再分享一下这个坑吧。
Redis的哨兵集群（Sentinel info 中的数目与实际数目差别等）_info sentinel 参数slaves只有一个-CSDN博客
下面是完成了哨兵集群搭建的结果
五、验证哨兵的选举机制
5.1 模仿Master节点宕机
1. 利用体系服务关闭 192.168.195.59 机器上的Redis服务
- #这样关闭redis服务,即使设置了保活Redis 也不会自动重启服务
- systemctl stop redis
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: 后续继续分享一些有效的知识, 关注点赞收藏咯。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
