前言
上一期实现了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的集群来解决以上的所有问题！
