Redis哨兵模式详解：故障转移与领导者选举步骤

【Redis】高可用之二：哨兵（sentinel）

在上一篇文章中，我们介绍了复制，正是因为复制中的漏洞，Sentinel才被创建。
什么是守卫？Sentinel会在后台巡查并监控主主机，看看是否有错误。
如果出现故障，从库会根据得票数自动转换为新的主库，继续对外服务（解决复制漏洞）。
简单来说，Sentinel是一种无人值守的运维机制。
以下是配置Redis一主两从的建议步骤。
配置一主两从后，将解压后的Redis/opt目录下的Sentinel.conf文件复制到专用的aqinredis文件夹中。
然后进行相关配置修改（上述可以根据配置Redis一主两从的文章修改Redis.conf配置文件）。
设置主机服务器以进行监控。
下面提供了所有需要配置的参数（如果按照流程直接复制即可，注意修改相应的参数）。
根据本文操作的三个单元的配置如下所示。
启动并执行redis-sentinel（记得添加软连接）并使用其配置文件来启动。
查看日志查看哨兵日志，可以看到正在监控的父子信息。
还有烧饼集团的信息。
原生配置文件也会自动写入一些内容（下图中红框）。
主机崩溃模拟。
接下来，我们模拟主机崩溃。
时，有以下几个问题需要注意。
过一段时间（给哨兵选举发生的时间），你可以尝试再次获取，你会发现原来的数据还在。
如果您尝试输入数据，您会发现它在6381上有效，但在6380上无效（它仍然是只读的）。
此时查看两个从设备的信息。
让我们检查守卫的日志，看看发生了什么。
Sentinel26379.logsentinel26380.logsentinel26381.log从上面的3个sentinel日志可以看到，sentinel确认主机宕机后（我们案例中配置的现状rm为2，即如果3个sentinel中至少有2个认为主机宕机了，他们确认主机宕机了），从机被投票给新的主机，最后决定从172.17切换主机。
0.26379至172.17.0.46381。
重启172.17.0.26379，查看其主从信息。
可以看到此时6379已经成为6381的从机（不会发生冲突主持人）。
由于6379当前是从属设备，因此无法执行写入操作。
总结总结一下我们上面提到的三个问题：故障转移、领导者选举、故障转移实现。
当主节点被判断为客观下线时，各个守护节点会先协商选举一个Leader，由Leader进行后续的故障转移，那么这个Leader是如何选择的呢？我们先从记录开始吧。
从Sentinel26379.log中可以看出，Sentinel26379ID为047a7c7a62a803bf8fc63b7033f9b52b4279c9c2，被Sentinel26381投票赞成，ID为b60ef35fc9e900b792f3b54a6ce49cc8b8d19ecc。
从Sentinel26380.log可以看出，Sentinel26380的ID是a5b3bcfca0e27c760ef4d0b2a88022146600c16c，他给自己投票了。
从Sentinel26381.log可以看出，Sentinel26381的ID是b60ef35fc9e900b792f3b54a6ce49cc8b8d19ecc，他也给自己投了票。
此时Sentinel26381有两票，Sentinel26380有一票，因此Sentinel26381被选举为Leader，并执行后续的故障转移过程以选择新的主机。
哨兵领袖是如何选拔的？使用raft算法，这个计算值得单独一篇文章(∇￣)/故障转移的具体步骤总结上面的故障转移操作都是由守卫自己自主完成的，完全不需要人工干预。
“可食用”护林员建议所以我们有下一篇文章-组合！敬请期待(￣∇￣)/~~~~~~~~~

在liunx（CentOS7）上搭建redis哨兵模式

CentOS7上创建RedisSentinel模式的详细步骤如下：首先进入Redis根目录，找到预设的sentinel.conf示例配置文件。
接下来我们重点配置Sentinel服务。
删除sentinel-26379.conf中不需要的部分，仅保留主要配置项：了解配置内容后，执行以下命令在根目录下创建另外两个Sentinel配置文件：配置文件创建完成后，将其复制到Redis从根目录开始。
三个哨兵，顺序如下：启动哨兵后，检查每个哨兵的配置文件变化。
例如，Sentinel1的配置可能如下：按照相同的方法初始化Sentinel2和Sentinel3，以确保Sentinel架构完整。
要测试Sentinel的主节点切换，首先观察并记录主节点进程ID，然后使用kill命令停止主节点。
此时，通过查看Sentinel的日志，我们可以观察到主从节点的变化：主节点关闭后，查看6381和6380端口的配置，会发现都做了相应的调整，确认Sentinel的故障转移功能正常。
最后，重启之前挂掉的主节点（6379端口）并检查配置。
你会发现它已经转为从节点了，确认了Sentinel模式的高可用。