Redis(八)--Redis哨兵模式

Redis(八)–Redis哨兵模式

这篇博客主要内容包括：

• 一、哨兵模式

• 二、 Redis Sentinel 架构

• 三、安装与配置：

  • 3.1 配置开启主从节点
  • 3.2 配置开启sentinel监控主节点（sentinel是特殊的redis）

• 四、java客户端

• 五、三个定时任务

• 六、主观下线和客观下线

• 七、领导者选举

• 八、故障转移

• 九、哨兵(Sentinel)总结

• 一道题： 哨兵们是怎么感知整个系统中的所有节点（主节点/从节点/哨兵节点）的？

一、哨兵模式：

1，是什么？

答：Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。

每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown)。若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。

虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)。

Sentinel（哨兵）是redis的高可用性解决方案：由一个或多个Sentinel实例组成的Sentinel系统，可以监视任意多个主服务器，并在这邪恶主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线的主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器替代已下线的主服务器继续处理命令的请求。

二、 Redis Sentinel 架构

三、安装与配置：

• 配置开启主从节点
• 配置开启sentinel监控主节点（sentinel是特殊的redis）
• 实际应该是多台机器。

sentinel的默认端口是 26379

sentinel是不存储数据的。红色框住的是它的一个核心配置。

• sentinel monitor mymaster 127.0.0.1 7000 2
  • mymaster 监控的sentinel的名字是什么
  • 127.0.0.1：IP地址
• sentinel down-after-milliseconds mymaster 30000
  • ping多少秒后不通就认为该master是有问题的 30秒
• sentinel parallel-syncs mymaster 1
  • 复制的设置，这设置：1 是每次只能复制一个

3.1 配置开启主从节点

首先在 redis的conf目录下，创建一个 7000.conf文件，内容为：

然后再根据7000.conf文件创建7001.conf和7002.conf文件。

这是一个偷懒的方法，然后将7001.conf和7002.conf文件中的配置信息值改为对应的7001和7002.
然后使用echo设置主从节点信息。
最后使用cat语句查看文件中的信息。

3.2 配置开启sentinel监控主节点（sentinel是特殊的redis）

在== redis/sentinel.conf文件中配置 sentinel==有关的信息

• 将redis/sentinel.conf文件拷贝到redis/conf文件夹下。 cp：拷贝
• 将所有的注释及所有的空行都注释掉。

主节点IP：127.0.0.1 端口是：7000。

配置好了之后可以启动：

配置好了一个sentinel之后，需要再配置两个sentinel。

配置好了之后可以使用启动命令启动三台 sentinel：

启动完成后，需要查看是否启动成功，执行下面的语句：

执行上面的语句后，可以看出三个sentinel启动成功了，这个时候我们使用== ./redis-cli -p 26379连接，连接成功后，输入info命令，可以查看具体的连接信息==，在下图中显示了info之后的结果，可以从红框中知道，三个sentinel可以互相感知到彼此的存在。

四、java客户端

我们需要的是服务端高可用和客户端高可用的结合。

sentinel应该知道谁是master。而客户端怎么知道master是否好使的呢，它是通过sentinel和客户端之间是发布订阅模式来实现的。

4.1 JedisSentinelPool

JedisSentinelPool的内部连接是连接的是master。

五、三个定时任务

• 每10秒每个 sentinel 对master 和 slave 执行info
  • 发现slave节点
  • 确认主从关系
• 每2秒每个 sentinel通过master节点的 cahnnel交换信息（pub / sub）
  • 通过 sentinel: hello频道交互
  • 交互对节点的“看法”和自身信息

• 每1秒每个 sentinel 对其他 sentinel 和redis执行ping
  • 心跳检测

六、主观下线和客观下线

主观下线：

Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例（包括主服务器、从服务器、其他的Sentinel在内的）发送PING命令，并通过实例返回的PING命令回复来判断实例是否存在。（若在down-after-millisecond毫秒内没有做出有效响应，哨兵就会将该实例在本结构中的状态标记为SRI_S_DOWN主观下线）

客观下线：

当Sentinel将一个主服务器判断为主观下线以后，为了确认这个主服务器是否真的下线了，他会向同样监视这一主服务器的其他Sentinel进行询问，看他们是否也认为主服务器已经进入下线状态（可以是主观下线或者是客观下线）。当Sentinel从其他Sentinel那里接受到足够数量的已下线判断之后，Sentinel就会将从服务器判定为客观下线，并对主服务器执行故障转移。

七、领导者选举

实现故障转移只需要一个sentinel节点就可以完成

• 原因：只有一个sentinel节点完成故障转移
• 选举：通过sentinel is-master-down-by-addr命令希望成为领导者
  • 每个做主观下线的Sentinel 节点向其他 Sentinel节点发送命令，要求将它设置为领导者
  • 收到命令的Sentinel节点如果没有同意通过其他Sentinel节点发送的命令，那么将同意该请求，否则拒绝
  • 如果该Sentinel节点发现自己的票数已经超过Sentinel集合半数且超过 quorum，那么它将成为领导者
  • 如果此过程有多个sentinel节点成为领导者，那么将等待一段时间重新进行选举。
• sentinel实现故障转移的过程：
  • 【步骤一】从slave节点中选出一个“合适的”节点作为新的master节点
  • 【步骤二】对上面的slave节点执行slaveof no one命令，让其成为 master节点
  • 【步骤三】 向剩余的slave节点发送命令，让它们成为新master节点的slave节点，复制规则和parallel-syncs参数有关。
  • 【步骤四】更新对原来master节点配置为slave，并保持着对其“关注”，当其回复后命令它去复制新的master节点。

选择“合适”slave节点：

• 选择slave-priority（slave节点优先级）最高的slave节点，如果存在则返回，不存在则继续。
• 选择复制偏移量最大的slave节点（复制的最完整）（即该slave节点与之前的master节点更相似），如果存在则返回，不存在则继续。（复制偏移量最大的从服务器就是保存着最新数据的从服务器）
• 选择runId最小的slave节点（也就是最近的一个，这样的话，保存着的是最新的数据）。

八、故障转移

在选举出领头的Sentinel之后，领头Sentinl将对已下线的主服务器执行故障转移操作，主要是包括以下三个步骤：

• 在已下线主服务器属下的所有从服务器里，挑选出一个从服务器，并将其转换主服务器
• 让已下线的主服务器属下的所有从服务器改成复制新的主服务器
• 将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，他会成为新的主服务器的从服务器。

九、哨兵(Sentinel)总结

1、Sentinel的作用：

• A、Master 状态监测
• B、如果Master 异常，则会进行Master-slave 转换，将其中一个Slave作为Master，将之前的Master作为Slave
• C、Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

2、Sentinel的工作方式:

• 1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。
• 2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
• 3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
• 4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，则Master会被标记为客观下线 。
• 5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 。
• 6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO命令的频率会从 10 秒一次改为每秒一次 。
• 7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
• 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

3.其他的一些：

• Redis Sentinel 是Redis的高可用实现方案：故障发现、故障自动转移、配置中心、客户端通知
• Redis Sentinel 中的Sentinel节点个数应该大于等于3，且最好为奇数
• Redis Sentinel 中数据节点与普通数据节点没有区别
• 客户端初始化时连接的是Sentinel节点集合，不再是具体的Redis节点。但Sentinel只是配置中心不是代理。
• Redis Sentinel 通过三个定时任务实现了Sentinel节点对于主节点、从节点、其余Sentinel节点控制
• Redsi Sentinel 在对节点做失败判定时分为主观下线和可观下线

补：一道题：

哨兵们是怎么感知整个系统中的所有节点（主节点/从节点/哨兵节点）的？

• 1.首先主节点的信息是配置在哨兵的配置文件中
• 2.哨兵节点会和配置的主节点建立起两条连接：命令连接和订阅连接
• 3.哨兵会通过命令连接每10s发送一个INFO命令，通过INFO命令，主节点会返回自己的runid和自己的从节点信息
• 4.哨兵会对这些从节点也建立两条连接：命令连接和订阅连接
• 5.哨兵通过命令连接向从节点发送INFO命令，获取到其他的一些信息（如：runid，role，从服务器的复制偏移量offset等）
• 6.因为哨兵对集群中的其他节点（主从节点）当前都有两条连接：命令连接和订阅连接
  • a.通过命令连接向服务器的_sntinel:hello频道发送一条信息，内容包括：自己的IP端口，run_id，配置纪元（后续投票会用到）等
  • b.通过订阅连接对服务器的_sentinel:hello频道做了监听，所以所有的向该频道发送的哨兵的消息都能被接收到
  • c.解析监听到的消息，进行分析提取，就可以知道还有哪些别的哨兵服务节点也在监听这些主从节点了，更新结构体将这些哨兵节点记录下来
  • d.向观察到的其他的哨兵节点建立命令连接，没有订阅连接。

感谢并参考：

https://blog.csdn.net/xiaojie_570/article/details/86510894
https://blog.csdn.net/qfc8930858/article/details/90143981