掌握Redis的Sentinel哨兵原理,助你拿到25k的offer!-CSDN博客

本文链接：https://blog.csdn.net/2401_85239883/article/details/140642384

[启动]

redis-server redis-7001.conf

redis-server redis-7002.conf

slave-1[配置]

port 7001

daemonize yes

pidfile /var/run/redis-7001.pid

logfile “7001.log”

dir “/opt/soft/redis/data/”

slaveof 127.0.0.1 7000

slave-2[配置]

port 7002

daemonize yes

pidfile /var/run/redis-7002.pid

logfile “7002.log”

dir “/opt/soft/redis/data/”

slaveof 127.0.0.1 7000

Sentinel 主要配置

port $(port)

dir “/opt/soft/redis/data/”

logfile " $(port).log"

sentinel monitor mymaster 127.0.0.1 7000 2

sentinel down-after-milliseconds mymaster 30000

sentinel parallel-syncs mymaster 1

sentinel failover-timeout mymaster 180000

演示

主节点配置

重定向
打印检查配置文件
启动

4 客户端

====================================================================

客户端实现基本原理-1

客户端实现基本原理-2

客户端实现基本原理-3 验证
客户端实现基本原理-4 通知(发布订阅))

客户端接入流程

Sentinel地址集合
masterName
不是代理模式

JedisSentinelPool sentinelPool = new JedisSentinelPool(masterName, sentinelSet, poolConfig, timeout);

Jedis jedis = null;

try {

jedis = redisSentinelPool.getResource();

//jedis command

} catch (Exception e) {

logger.error(e.getMessage(), e);

} finally {

if (jedis != null)

jedis.close();

}

5 定时任务

=====================================================================

每10s 每个 sentinel 对 master 和 replica 执行 INFO 命令

发现 replica 节点
确认主从关系

每 2s 每个 sentinel 通过 master 节点的channel交换信息(pub/sub)

通过 sentinel :java频道交互
交互对节点的"看法”和自身信息

每 1s 每个 sentinel 对其他 sentinel 和 redis 执行ping

心跳检测，失败判定依据

6 主观下线和客观下线

==========================================================================

主观下线(Subjectively Down,SDOWN)

单个 Sentinel 节点对服务器做出的下线判断，即单个 Sentinel 认为某个服务下线（有可能是接收不到订阅，之间的网络不通等一系列原因）。

注意主观下线是每个sentinel节点对Redis节点失败的"偏见”。所以还需要客观下线机制。

客观下线(Objectively Down,ODOWN)

多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过命令互相交流之后，得出的服务器下线判断，然后开启 failover。

只有在足够数量( 超过quorum个)的 Sentinel 都将一个服务器标记为主观下线之后，服务器才会被标记为客观下线（ODOWN）。只有当 Master 被认定为客观下线时，才会发生故障迁移。

仲裁

仲裁指配置文件中的 quorum 参数。某个 Sentinel 先将 Master 节点标记为主观下线，然后会将这个判定通过 sentinel is-master-down-by-addr 命令询问其他 Sentinel 节点是否也同样认为该 addr 的 Master 节点要做主观下线。

sentinel monitor < port>

sentinel monitor myMaster 127.0.0.1 6379 2

sentinel down-after-milliseconds < masterName> < timeout>

sentinel down-after-milliseconds mymaster 30000

最后当达成这一共识的 Sentinel 个数达到前面说的 quorum 设置的值时，该 Master 节点会被认定为客观下线并进行故障转移。

quorum 值一般设为 Sentinel 个数的二分之一加 1，例如 3 个 Sentinel 就设为 2。

综上可得

哨兵工作原理

每个 Sentinel 以 1次/s 向它所知的 Master，Slave 以及其他 Sentinel 节点发送一个 PING
若一个实例距离最后一次有效回复 PING 的时间超过配置文件 down-after-milliseconds，则该实例会被 Sentinel 标记为 主观下线
若一个 Master 被标记为主观下线，则正在监视该 Master 的所有 Sentinel 会 1次/s 确认 Master 是否真的进入主观下线状态
当有足够数量 Sentinel（大于等于配置文件指定的值）在指定时间范围内确认 Master 的确进入主观下线状态，则 Master 会被标记为 客观下线
若 Master 处于 ODOWN 状态，则投票自动选出新Master。将剩余从节点指向新Master继续数据复制
在正常情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有 Master，Slave 发送 INFO 命令；当 Master 被 Sentinel 标记为客观下线时，Sentinel 向已下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次（因为原来是稳定的，10s 一次info就是为了看看有没有新加入的 sentinel，但现在故障了，所以要尽快将环境稳定好，快速确认完主从关系）
若没有足够数量 Sentinel 同意 Master 已经下线，Master 的客观下线状态会被移除。若 Master 重新向 Sentinel 的 PING 命令返回有效回复，Master 的主观下线状态就会被移除。