1.1 Redis哨兵模式Sentinel实战
从Redis 2.8 版本开始，Redis 官方引入高可用方案：哨兵（Sentinel）模式。众所周知在 Redis 主从复制模式中，主从模式不具备自动恢复的功能，当主服务器（Master）宕机后，需要手动把从服务器（Slave）切换为主服务器。在这个过程中，需要人为干预，还会造成一段时间内服务器处于不可用状态，同时数据安全性也得不到保障。
Redis Sentinel 哨兵模式，它弥补了主从模式的不足。Sentinel 模式通过监控Master和Slave，获取主机上（Redis服务）的工作状态是否正常，当主机发生故障时， Sentinel 会自动进行 Failover（即故障转移），并将其监控的从机提升主服务器（Master），从而保证了系统的高可用性。
哨兵模式由两部分组成，哨兵节点和数据节点，其中哨兵节点是特殊的 Redis 节点，不存储数据;而主节点和从节点被称为是数据节点。
哨兵(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)。
1.1.1 Sentinel工作原理
Sentinel服务启动之后，会读取sentinel.conf主配置文件，并通过文件中指定的Sentinel monitor 配置寻找要监控的Master数据库。其中Master-name是由一个大小写字母、数字、和“._-”组成的数据库主库名字，为了考虑到主库的IP地址和端口可能在故障切换后发生变化，所以还需要ip和port来标示这个主库。一个哨兵可监控多个主从系统从而形成网状结构，如图所示：
Sentinel与监控的主库建立连接完成后，Sentinel定时执行以下操作： - 每10s会向Master数据库和从数据库发送INFO命令;
- 每1s向Master、Slave以及其他哨兵节点发送PING命令;
- 每2s向Master和Slave的__sentiel__:hello频道发送自己的信息来宣布自己的存在，同时该过程也是实现哨兵之间自动发现的基础。
Sentinel启动后，向主库发送INFO命令使得Sentinel可以获取当前主库的相关信息（包括运行的ID，复制信息、以及属于该主库的从库节点信息）。
1.1.2 Sentinel主要功能
集群监控
负责监控Redis Master和Slave进程是否正常工作;
消息通知
如果某个Redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员;
故障转移
如果Master node挂掉了，会自动转移到Slave node上;
配置中心
如果故障转移发生了，会通知client客户端新的Master地址。
1.1.3 Sdown和Odown概念
要深入理解Sentinel模式主从切换过程，就要对Sdown和Odown概念有一个清晰的认识和了解。
SDOWN概念
Subjectively Down，即主观下线，指的是单个Sentinel对Redis实例作出的下线状态判断;
ODOWN概念
Objectively Down，即客户端下线，指多个 Sentinel 实例在对同一个Redis做出 SDOWN 判断，并且通过 Sentinel is-Master-down-by-addr 命令互相交流之后，得出的Redis实例下线判断。
单个Sentinel 可以通过向另一个Sentinel发送Sentinel is-Master-down-by-addr 命令来询问对方是否认为给定的Redis实例已下线。从Sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。这个时间在配置中通过Master-down-after-milliseconds参数配置。
从SDOWN切换到ODOWN不需要任何一致性算法，只需要一个gossip协议：如果一个Sentinel收到了足够多的Sentinel发来消息告诉它某个Master已经down掉了，SDOWN状态就会变成ODOWN状态。如果之后Master可用了，这个状态就会相应地被清理掉。
真正进行Failover需要一个授权的过程，这个授权的过程即是leader选取过程，但是所有的Failover都开始于一个ODOWN状态。ODOWN状态只适用于Master，对于不是Master的Redis节点Sentinel之间不需要任何协商，Slave和Sentinel不会有ODOWN状态。
1.1.4 Sentinel模式实战
1) Redis哨兵模式环境，机器列表如下：
Redis哨兵： 192.168.1.148 Redis主库： 192.168.1.145 Redis从库： 192.168.1.146 |
2) 192.168.1.148服务器上，安装部署Redis哨兵服务，代码如下：
#下载Redis软件包；
#通过Tar解压软件包；
tar zxf redis-6.2.7.tar.gz
#Cd切换至Redis源代码目录；
cd redis-6.2.7/
#编译&安装；
make PREFIX=/usr/local/redis install
#拷贝setninel配置文件；
cp sentinel.conf /usr/local/redis/ |
3) 将/usr/local/redis/bin/目录加入至环境变量配置文件/etc/profile末尾，然后Shell终端执行source /etc/profile让环境变量生效。
export PATH=/usr/local/redis/bin: PATH |
4) 修改哨兵模式配置文件Sentinel.conf，设置Monitor监控的Master Redis IP和端口，信息，代码如下：
port 26379 daemonize no pidfile /var/run/redis-sentinel.pid logfile "" dir /tmp sentinel monitor mymaster 192.168.1.145 6379 1 sentinel down-after-milliseconds mymaster 5000 acllog-max-len 128 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 sentinel deny-scripts-reconfig yes SENTINEL resolve-hostnames no SENTINEL announce-hostnames no |
5) Nohup后台启动Redis哨兵服务，操作命令如下：
nohup /usr/local/redis/bin/redis-sentinel /usr/local/redis/sentinel.conf & |
6）根据如上操作步骤和指令，查看redis-sentinel服务状态和端口信息，如图所示：
7）验证Master宕机，是否将Slave角色设置为Master，同时当原来的Master启动之后，自动设置为Slave角色。如图所示：
| 
发表于 2024-1-13 12:23:10
