Redis部署哨兵模式

一、哨兵模式

基本概念

在主从复制的架构中一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令其他从节点去复制新的主节点，整个过程都需要人工干预。
　　Redis-sentinel是Redis的作者antirez，因为Redis集群的被各大公司使用，每个公司要写自己的集群管理工具，于是antirez花了几个星期写出了Redis-sentinel。用现在流行的话可以说就是一个“哨兵机器人”，给“哨兵机器人”进行相应的配置之后，这个"机器人"可以7*24小时工作，它能能够自动帮助你做一些事情，如监控，提醒，自动处理故障等。

-故障转移不及时的严重后果：

• 应用方来说无法及时感知到主节点的变化，必然会造成一定的写数据丢失和读数据错误，甚至可能造成应用方服务不可用。
• Redis的运维方来说，整个故障转移的过程是需要人工来介入的，故障转移实时性和准确性上都无法得到保障

传统运维监控故障转移过程：

1. 主节点发生故障后，客户端（client）连接主节点失败，所有的从节点与主节点连接失败造成复制中断。
2. 如果主节点无法正常启动，需要选出一个从节点，对其执行slaveof no one命令使其成为新的主节点。
3. 原来的从节点成为新的主节点后，更新应用方的主节点信息，重新启动应用方。
4. 客户端命令另一个从节点去复制新的主节点（new-master），slaveof host port
5. 待原来的主节点恢复后，让它去复制新的主节点。

自动化故障转移需要解决的问题：

• 判断节点不可达的机制是否健全和标准？
• 如果有多个从节点，怎样保证只有一个被晋升为主节点？
• 通知客户端新的主节点机制是否足够健壮？

Redis Sentinel具有以下几个功能：

• 监控：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。

• 通知：Sentinel节点会将故障转移的结果通知给应用方。

• 故障转移：实现从节点晋升为主节点并维护后续正确的主从关系。

• 配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。

使用Sentinel架构的好处：

• 对于节点的故障判断是由多个Sentinel节点共同完成，这样可以有效地防止误判。
• Sentinel节点集合是由若干个Sentinel节点组成的，这样即使个别Sentinel节点不可用，整个Sentinel节点集合依然是健壮的。

当主节点出现故障时，Redis Sentinel能自动完成故障发现和转移，并通知应用方，从而实现真正的高可用。
　　
　 Redis Sentinel是一个分布式架构，其中包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据（主从）节点和其余Sentinel节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成自动故障转移的工作，同时会将这个变化实时通知给Redis应用方。
　　单个sentinel进程来监控redis集群是不可靠的，当sentinel进程宕掉后(sentinel本身也有单点问题，single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群，这样有几个好处：

• 有一些sentinel进程宕掉了，依然可以进行redis集群的主备切换；
• 如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）;
• 如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息
• Sentinel节点不应该部署在一台物理“机器”上。同一台物理机意味着如果这台机器有什么硬件故障，所有的虚拟机都会受到影响，为了实现Sentinel节点集合真正的高可用。
• 部署至少三个且奇数个的Sentinel节点。增加Sentinel节点的个数提高对于故障判定的准确性，因为故障转移时领导者选举采用过半原则，奇数个节点可以最低限度满足该条件。

Sentinel架构图：

Sentinel故障转移过程：

1. 每个Sentinel节点通过定期监控发现主节点出现了故障。

２. 多个Sentinel节点对主节点的故障达成一致，选举出一个节点作为领导者负责故障转移

3、Sentinel领导者节点执行了故障转移

二、部署哨兵

1. 启动master节点
redis-6379.conf配置：

#redis以守护进程方式运行
daemonize yes
#日志文件
logfile 6379.log
#rdb文件
dbfilename dump-6379.rdb

redis-sever redis-6379.conf
2. 启动从节点
redis-6380.conf配置：

#redis以守护进程方式运行
daemonize yes
#日志文件
logfile “6380.log”
#rdb文件
dbfilename “dump-6380.rdb”
#设置主节点
slaveof 127.0.0.1 6379

redis-server redis-6380.conf
redis-server redis-6381.conf

3. 确认主从关系
info replication 或 role命令

4. 配置Sentinel节点
sentinel-26379.conf配置:
port 26379
daemonize yes
logfile “26379.log”
#sentinel monitor
#监控127.0.0.1:6379这个主节点，别名my-master，至少2个Sentinel节点认为失败时做故障转移
sentinel monitor my-master 127.0.0.1 6379 2

#sentinel down-after-milliseconds
#超过指定秒没有收到节点回复，判为故障下线
sentinel down-after-milliseconds my-master 30000

#sentinel parallel-syncs
#故障转移时的从节点向主节点发起并发复制请求的数量
sentinel parallel-syncs my-master 1

#sentinel failover-timeout
#故障转移超时时间
sentinel failover-timeout my-master 180000

5. 启动Sentinel节点。
两种方式启动Sentinel节点：
a、使用redis-sentinel命令：
redis-sentinel sentinel-26379.conf
b、使用redis-server命令加–sentinel参数：
redis-server sentinel-26379.conf --sentinel

6. 启动三个Sentinel节点

两种方式启动Sentinel节点：
a、使用redis-sentinel命令：
redis-sentinel sentinel-26379.conf
b、使用redis-server命令加–sentinel参数：
redis-server sentinel-26379.conf --sentinel
7. 确认
info sentinel