【Redis】高可用之二：哨兵（sentinel）
最新回答
懵蓝初梦
2021-01-30 11:54:58
什么是哨兵？哨兵会巡查监控后台master主机，查看是否存在故障。如果故障了，就会根据投票数自动将某一个从库转换为新主库，继续对外服务（解决复制的痛点）。
简单来讲，哨兵就是一种无人值守的运维机制。
以下是配置Redis一主二从的步骤建议。
配置好一主二从后，将解压缩后的Redis/opt目录下的sentinel.conf 复制到自定义的aqinredis文件夹中。
接着进行相关配置修改（以上都可以按照配置Redis一主二从的文章对配置文件Redis.conf的修改）。
设置要监控的主机服务器。
下面提供需要配置的全部参数（跟着操作的同学直接拷贝即可，注意对应参数的修改）。
按本文操作的3台配置分别如下图。
启动
执行redis-sentinel启动（记得添加软连接）
依次使用各自的配置文件启动
启动成功～
查看日志
查看哨兵日志，可以看到其监控的主从信息，以及烧饼集群的信息。
原先的配置文件也会自动写入一些内容（下图红框框）。
模拟主机宕机
接下来我们模拟主机宕机。
此时有以下问题需要注意。
过一段时间以后（给哨兵选举的时间）再尝试获取可以发现，原先的数据还在。
尝试插入数据，会发现6381上可以，6380不行（还是只读）。
查看下此时两台从机的信息。
我们查看下sentinel日志，看看发生了什么。
sentinel26379.log
sentinel26380.log
sentinel26381.log
从上面三个哨兵日志可以看到，哨兵在确认主机宕机后（我们的案例配置的quorum是2，即3个哨兵中至少有2个认为主机宕机就确认主机宕机），对从机进行了新主机的投票选举，最终决定将主机从172.17.0.2 6379切换成了172.17.0.4 6381。
重启172.17.0.2 6379，并查看其主从信息。
可以看到，此时6379变成了6381的从机（不会出现主机冲突）。
由于目前6379是从机，因此也无法进行写操作。
总结
总结我们上面提到的三个问题：故障转移、选举Leader、实施故障转移。
当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者（leader），并由该leader进行接下来的故障迁移（failover），那么这个Leader是如何选择出来的呢？
我们还是从日志入手。
由sentinel26379.log可以看到，sentinel26379的ID是047a7c7a62a803bf8fc63b7033f9b52b4279c9c2，他把票投给了ID为b60ef35fc9e900b792f3b54a6ce49cc8b8d19ecc的sentinel26381。
由sentinel26380.log可以看到，sentinel26380的ID是a5b3bcfca0e27c760ef4d0b2a88022146600c16c，他把票投给了他自己。
由sentinel26381.log可以看到，sentinel26381的ID是b60ef35fc9e900b792f3b54a6ce49cc8b8d19ecc，他也把票投给了他自己。
此时sentinel26381有2票，sentinel26380有1票，因此，sentinel26381当选leader，并执行后续的故障转移流程选出新的主机。
哨兵的Leader是怎么选的？
通过raft算法，这个算值得单独出一篇来讲(￣∇￣)/
故障转移具体步骤
总结
上述的failover操作均由sentinel自己独立完成，完全无需人工干预。
哨兵“食用”建议
于是我们有了下一篇文章——集群！敬请期待(￣∇￣)/ ～～～～～～～～～
热门标签
