掌握Redis的Sentinel哨兵原理,助你拿到25k的offer

最新推荐文章于 2024-09-17 17:10:02 发布

2401_84046545

最新推荐文章于 2024-09-17 17:10:02 发布

阅读量697

点赞数 11

分类专栏：程序员文章标签： redis sentinel java

本文链接：https://blog.csdn.net/2401_84046545/article/details/138044944

版权

程序员专栏收录该内容

477 篇文章 0 订阅

订阅专栏

±—+ ±—+

| M1 |---------| R1 |

| S1 | | S2 |

±—+ ±—+

Configuration: quorum = 1

master宕机，s1和s2中只要有1个哨兵认为master宕机就可以进行切换，同时会在s1和s2中选举出一个执行故障转移.

但此时，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2

2个哨兵的majority=2

3个哨兵的majority=2

4个哨兵的majority=2

5个哨兵的majority=3

2个哨兵都运行着，就可以允许执行故障转移

若整个M1和S1运行的机器宕机了，那么哨兵仅剩1个，此时就无majority来允许执行故障转移，虽然另外一台机器还有一个R1，但故障转移不会执行

3节点哨兵集群

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

±—+

| M1 |

| S1 |

±—+

±—+ | ±—+

| R2 |----±—| R3 |

| S2 | | S3 |

±—+ ±—+

Configuration: quorum = 2，majority

若M1节点宕机了，还剩下2个哨兵，S2和S3可以一致认为master宕机了，然后选举出一个来执行故障转移

同时3个哨兵的majority是2，所以余存的2个哨兵运行着，就可执行故障转移

2 Redis Sentinel 架构

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

Redis Sentinel故障转移

多个sentinel发现并确认master有问题。
选举出一个sentinel作为领导。
选出一个slave作为master.
通知其余slave成为新的master的slave.
通知客户端主从变化
等待老的master复活成为新master的slave

可监控多套

3 安装与配置

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

配置开启主从节点
配置开启sentinel监控主节点。(sentinel是特殊的redis)
实际应该多机器
详细配置节点

Redis 主节点

[启动]

redis-server redis- 7000.conf

[配置]

port 7000

daemonize yes

pidfile /var/run/redis-7000.pid

logfile “7000.log”

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

Redis 从节点

[启动]

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 主观下线、客观下线

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

6.1 主观下线(Subjectively Down，SDOWN)

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

主观下线是每个sentinel节点对Redis节点失败的偏见。

所以还需客观下线机制。

6.2 客观下线(Objectively Down，ODOWN)

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

只有在足够数量( 超过quorum个)的 Sentinel 都将一个服务器标记为主观下线后，服务器才会被标记为客观下线（ODOWN）。

只有当 M 被认定为客观下线时，才会发生故障迁移。

仲裁

仲裁指配置文件中的 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 的主观下线状态就会被移除。

7 领导者选举

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

原因：只有一个sentinel节点完成故障转移。

选举：通过sentinel is-master-down-by-addr命令都希望成为领导者：

每个做主观下线的Sentinel节点向其他Sentinel节点发送命令，要求将它设置为领导者
收到命令的Sentinel节点如果没有同意通过其他Sentinel节点发送的命令，那么将同意该请求，否则拒绝
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。