Redis哨兵（Sentinel）模式

前言

上一期实现了Redis的主从复制架构，由于主从模式在主节点宕机故障时整个Redis服务都不能再执行写操作，而无法保证Redis在整个系统中的高可用。

Redis提供了Sentinel哨兵机制来解决以上问题，当哨兵服务监测到master下线或宕机，哨兵会自动选举一个slave作为新的master，然后通过发布订阅模式通知其他所有的从节点，修改配置文件，让它们切换主机

简单的说哨兵就是带有自动故障转移功能的主从架构！

哨兵架构原理

如下是单个哨兵

**原理：**哨兵是通过发送命令到各个节点，然后等待Redis服务器响应的方式，来监控运行的各个Redis节点的状态

若某一时刻由于网络延迟等原因（但实际master并未出现故障），哨兵一直未收到master节点的状态响应，而选举了新的master，导致出现了多个master，引起主从复制错乱，这种情况称为——脑裂

脑裂情况的存在实际中会使用多哨兵模式：哨兵除了监控各个Redis服务节点的状态之外，哨兵之间也会互相监控

假设master节点故障，哨兵1先检测到了这个结果，仅仅是哨兵1主观的认为master节点不可用，系统并不会马上进行failover故障转移，选举新master的过程，当一半以上的哨兵也检测到master不可用时，那么哨兵之间就会进行一次投票选举，选举一个slave作为新的master，再由一个哨兵进行failover操作。切换成功后，就会通过发布订阅模式，通知各个哨兵和slave切换master

一主二从三哨兵

搭建哨兵架构

在上一期搭建好的Redis主从复制架构的基础上，完成Redis多哨兵模式的搭建

1、在redis源码包目录下复制出sentinel.conf文件到redis安装的根目录并按如下修改

- sentinel1
	# 开启守护线程的(后台)方式启动
	daemonize  yes
	# 关闭保护模式
	protected-mode no
	# 哨兵服务默认端口是26379
	port 26379
	# 哨兵模式默认工作目录
	dir /tmp
    # 监控的redis主节点服务，mymaster是可自定义的服务名
    # 2 代表有两个或两个以上的哨兵认为master不可用的时候，才会进行故障转移操作
	sentinel monitor mymaster 192.168.31.161 8001 2
	# redis.conf中开启了requirepass，所有连接Redis服务的客户端(包括哨兵)都要提供访问密码
	sentinel auth-pass mymaster 123456
	
- sentinel2
	daemonize  yes
	protected-mode no
	port 26380
	dir /tmp
	sentinel monitor mymaster 192.168.31.161 8001 2
	sentinel auth-pass mymaster 123456
	
- sentinel3
	daemonize  yes
	protected-mode no
	port 26381
	dir /tmp
	sentinel monitor mymaster 192.168.31.161 8001 2
	sentinel auth-pass mymaster 123456

2、配置好三台机的sentinel.conf文件后，先启动三个Redis服务，再启动三个哨兵

**启动三个哨兵：**这里为了方便看日志，在sentinel.conf配置文件中可以先关闭后台启动方式daemonize no

# 在redis的bin目录下执行
./redis-sentinel ../sentinel.conf

三个哨兵启动后，可在任一个中看到检测出的主从节点，已经另外两个哨兵（互相监控）

3、验证sentinel哨兵机制

• 使用redis-cli客户端进入任意一个哨兵服务查看sentinel信息
• 宕掉8001的redis主节点服务，查看是否自动选举出了新的master

./redis-cli -p 26379
> info sentinel # 查看当前哨兵服务的信息

如下，手动宕掉(停掉进程)8001的redis主节点服务，当有2个哨兵发现8001的服务shutdown后，这里哨兵重新选举了8003的服务作为新的master节点，并由26381这个哨兵去做了failover故障转移，并通知另两个哨兵做了主从切换

26381哨兵中的日志：

26379和26380两个哨兵中的日志一样：

8003的服务作为新的master节点，原来为只读，此时可在8003上进行写操作

其它细节：

1）故障转移之后，三个哨兵sentinel.conf配置文件中的sentinel monitorIP和端口已自动修改为新的master节点的信息

2）原来的master节点8001已经down了，重新启动8001的redis服务它会作为一个从节点提供服务（等你回来后，你已不再是leader）

后记

redis哨兵是带有自动故障转移功能的redis主从架构，但这两种模式它们都无法解决单节点的并发压力和物理上线问题

• 这两种模式下，客户端所有的写操作(请求)都是始终在一个节点上，在并发非常大的情况下单个节点无法处理导致阻塞设置宕机（即单节点的高并发）
• redis是NoSQL，所有的写请求都落在一个节点的内存中，并且redis默认是开启持久化(AOF/RDB），对这个节点的内存和磁盘的IO要求就非常的高（单节点物理上线问题）

此时就需要Redis的集群来解决以上的所有问题！