Redis哨兵(非集群 Rrdis 的高可用性 )

Redis哨兵(非集群 Rrdis 的高可用性 )

1. 什么是哨兵

吹哨人巡查监控后台 master 主机是否故障,如果故障了根据投票数自动将某一个从库转换为新主库,继续对外服务

Redis哨兵在不使用Redis集群时为Redis提供高可用性

2. 作用

无人值守运维

3. 哨兵作为分布式系统

Redis Sentinel是一个分布式系统：

Sentinel 本身设计为在有多个 Sentinel 进程协同的配置中运行。让多个 Sentinel 流程协作的优势如下：

1. 当多个哨兵同意认为主节点不再可用时，将执行故障检测。这降低了误报的可能性。
2. 即使不是所有的 Sentinel 进程都在工作，Sentinel 也能正常工作，使系统能够抵御故障。毕竟，拥有一个本身就是单点故障的故障转移系统没有任何意义。

哨兵、Redis 实例（主实例和副本实例）和客户端的总和 连接到Sentinel和Redis，也是一个更大的分布式系统，具有 特定属性。在本文档中，概念将逐步介绍 从基本信息开始，了解基本信息 Sentinel 的属性，到更复杂的信息（可选）在 以了解哨兵究竟是如何工作的。

4. 使用Redis哨兵

sentinel.conf文件中的重要配置

==

==

==

==

==

5. Running Sentinel

redis-sentinel sentinel23679.conf --sentinel
//启动配置文件为sentinel23679的哨兵

6. 手动模拟主机下线

在6379输入: shutdown

我们发现在第一时间,在6380端口get key时
Error: Server closed the connection
但又过了5s左右,数据就恢复了,get key 能拿到值

同时发现,6381成为了主机(6379挂掉前是从机),6380还是从机

我们来看以下哨兵配置文件 sentinel26370.conf:

我们同时发现,6379也称为6381的小弟,即使回来也是从机身份

了解一下Broken Pipe

注意事项

6379的配置文件发生变化

6381的配置文件发生变化

首先会执行slaveof no one

所以说6380配置文件也会发生改变

==

==

可以同时监控多个master,一个一行

7. 哨兵运行流程 和 选举原理

SDown主观下线

Sdown是单个sentinel自己主观上检测到的关于master的状态,从sentinel的角度来看,如果发送了PING心跳后,在一定时间内没有收到合法的回复,就达到了SDOWN的条件

sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长短

ODown客观下线

ODown需要一定数量的sentinel,多个哨兵达成一致意见才能认为一个master客观上已经宕掉

选举出领导者哨兵

咋选出来的?

由兵王开始推动故障切换流程并选出一个新的master

选举master的选举算法

• 先看权限
• 再看复制偏移量,谁大选谁
• 否则就看谁运行ID小选谁

8. 哨兵使用建议