java 开发框架 Redis 之 sentinel 和集群

 

一. redis 高可用方案–sentinel（哨兵模式）

当我们搭建好 redis 主从复制方案后会发现一个问题，那就是当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，java培训同时在手动切过程中也会导致 redis 服务器写入功能不可用。所以需要一种方法可以完成 Master 故障后可以自动的将一个 Slave 切换为 Master，这个时候就有了 sentinel 哨兵模式。

哨兵模式简介：

sentinel 是官方提供的高可用方案，其原理是哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。同时 sentinel 是一个分布式系统，可以在一个架构中运行多个 Sentinel 进程，可以做到 sentinel 的高可用。

sentinel 工作过程：

• 通过向主服务器和从服务器发送 ping 命令，让服务器返回运行状态。

• 当哨兵监测到 master 宕机，会自动将一个 slave 切换成 master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

关于 sentinel 的三个定时任务：

• 每 1 秒每个 sentinel 对其他 sentinel 和 redis 节点执行 ping 操作，心跳检测。

• 每 10 秒每个 sentinel 会对 master 和 slave 执行 info 命令，目的是发现 slave 结点，确定主从关系。

• 每 2 秒每个 sentinel 通过 master 节点的 channel 交换信息（pub/sub）。master 节点上有一个发布订阅的频道(sentinel:hello)。sentinel 节点通过__sentinel__:hello 频道进行信息交换(对节点的"看法"和自身的信息)，达成共识.

sentinel 网络：

sentinel 是一个分布式系统，可以在一个架构中运行多个 Sentinel 进程。所以监控同一个 Master 的 Sentinel 会自动连接，组成一个分布式的 Sentinel 网络，互相通信并交换彼此关于被监视服务器信息。

 

sentinel 网络故障修复原理：

1.主观下线：

当主服务器发生故障时，此时一个 sentinel 发现了故障，系统并不会马上进行 failover 过程（这个现象称为主观下线），它会向网络中的其他 Sentinel 进行确认。

2.客观下线：

接着其他 Sentinel 也陆续发现故障，这个时候其中一个 Sentinel 就会发起投票。一定数量的哨兵(在配置文件中指定)确认 Master 被标记为主观下线，此时将 Master 标记为客观下线。

3.sentinel 的 leader 选举：

要想完成故障切换（将故障 master 剔除，并将一个 slave 提升为 master）就必须先选举一个 leader。最先发现故障的 sentinel 向其他哨兵发起请求成为 leader，其他哨兵在没有同意别的哨兵的 leader 请求时，就会把票投给该 sentinel。当半数以上的 sentinel 投票通过后就认定该 sentinel 为 leader。接下来的故障切换有该 leader 完成。

4.master 选举：

leader 选好后将故障 master 剔除，从 slave 中挑选一个成为 master。遵照的原则如下：

• slave 的优先级

• slave 从 master 那同步的数据量，那个 slave 多就优先。

5.新 Master 再通过发布订阅模式通知所有 sentinel 更新监控主机信息。

6.故障的主服务器修复后将成为从服务器继续工作。

故障发生

 

故障切换 

Master 重新上线后 

哨兵模式配置

本实验在一台机器上完成，创建不同端口的 redis 实例。