@
在开始之前，我们先来看看Redis的主从复制
主从复制原理：
- 从服务器向主服务器发送
SYNC命令。- 主服务器接到
SYNC命令后，会调用BGSAVE命令，创建一个RDB文件，并使用缓冲区记录接下来执行的所有写命令。- 当主服务器执行完
BGSAVE命令后，会向从服务器发送RDB文件，而从服务器则会接收并执行这个文件。- 主服务器将缓冲区存储的所有写命令发送给从服务器执行。
---------
Redis主从复制使用的是RDB备份方式来同步主从服务器的数据的。
同步开始之后，通过主库命令传播的方式，主动复制方式实现。
2.8以后实现PSYNC饿机制，实现断线重连。
Redis主从复制的背景问题
Reids主从复制可将主节点数据同步给从节点，从节点此时有两个作用：
- 一旦主节点宕机，从节点作为主节点的备份可以随时顶上来.
- 扩展主节点的读能力，分担主节点的读压力.
.
一旦主节点宕机，从节点上位，那么就需要人为修改所有应用方的主节点地址（指定新的master地址），还需要命令所有从节点复制新的主节点.
这个问题很麻烦，而redis-sentinel就可以很好的解决这个问题.
Redis-Sentinel
Redis-Sentinel是redis官方推荐的高可用性能解决方案，当用redis做master-slave的高可用时，如果master本机宕机，redis本身或者客户端都没有实现主从切换的功能，而redis-sentinel是一个独立运行的进程，用于监控多个maser-slave集群，其自动发现master宕机，进行自动切换：slave > master
Sentinel主要功能
- 不时的监控redis是否良好运行，如果节点不可达就会对节点做下线标示.
- 如果被标示的是主节点，则sentinel就会和其它的sentinel节点“协商”，如果其它节点也认为主节点不可达，就会选举一个sentinel节点来完成自动故障转移.
- 在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换.
Sentinel工作原理
每一个Sentinel以每秒钟一次的频率向它所知的所有Master、Slave以及其它Sentinel实例发送一个PING命令.
如果一个实例(Instance)距离最后一次有效回复PING命令的时间超过down-after-milliseconds选项所指定的值，则这个实例会被Sentinel标记为主观下线.
如果一个Master被标记为主观下线，则正在监视这个Master的所有Sentinel都会以每秒一次的频率确认这个Master的确进入了主观下线状态.
当有足够数量的Sentinel(大于等于配置文件中指定的值)在指定的时间范围内确认这个Master的确进入了主观下线状态，那么这个Master会被标记为客观下线.
在一般情况下，每个Sentinel会以每10秒一次的频率向它已知的所有Master、Slave发送INFO命令.
当有Master被Sentinel标记为客观下线时，Sentinel向下线的Master的所有Slave发送INFO命令的频率会从10秒一次改为每秒一次.
若没有足够数量的Sentinel同意Master已经下线，则此Master的客观下线状态就会被移除.
主观下线和客观下线
主观下线
Subjectively Down，简称SDOWN，指的是当前Sentinel实例对某个redis服务器做出的下线判断
客观下线
Objectively Down，简称ODOWN，指的是多个Sentinel实例在对Master Server做出SDOWN判断，并且通过SENTINEL is-master-down-by-addr命令互相交流之后，得出的Master Server下线判断，然后开启failover.
SDOWN
适合于Master和Slave，只要一个Sentinel发现Master进入了ODOWN，这个Sentinel就可能会被其它Sentinel推选出，并对下线的主服务器执行自动故障迁移操作.
ODOWN
只适用于Master，对于Slave的Redis实例，Sentinel在将它们判断为下线前不需要进行协商，所以Slave的Sentinel永远不会到达ODOWN.
主从复制架构图
Redis Sentinel架构图
Sentinel是redis一个进程，不存储数据，只负责监控redis.
关于Redis的发布订阅，详见此文献【Redis发布订阅】
开始配置主从复制
搭建环境：
一台Redis服务器（版本redis-5.0.2）
三个Redis实例（一个主节点Master，两个从节点Slave）
配置文件
主节点 7001.conf
port 7001 daemonize yes logfile /usr/local/redis-5.0.2/logs/7001.log dbfilename dump-7001.rdb dir /usr/local/redis-5.0.2/db/7001/
从节点 7002.conf
port 7002 daemonize yes logfile /usr/local/redis-5.0.2/logs/7002.log dbfilename dump-7002.rdb dir /usr/local/redis-5.0.2/db/7002/ # 指定主节点 slaveof 127.0.0.1 7001
从节点 7003.conf
port 7003 daemonize yes logfile /usr/local/redis-5.0.2/logs/7003.log dbfilename dump-7003.rdb dir /usr/local/redis-5.0.2/db/7003/ # 指定主节点 slaveof 127.0.0.1 7001
验证主从关系
在主节点上查看主从通信关系
在从节点上查看主从通信关系
此时，一主双从已经搭建完毕了，可在Master上写入些数据，然后在Slave查看.
开始配置Redis Sentinel
搭建环境：
包含上面搭建主从的所有环境
还增加了三个redis-sentinel实例（27001.conf、27002.conf、27003.conf）
配置文件
27001.conf
port 27001 daemonize yes dir "/usr/local/redis-5.0.2/db/" logfile "/usr/local/redis-5.0.2/logs/27001.conf" sentinel monitor mymaster 127.0.0.1 7001 2 # mymaster：主节点的别名 # 当前Sentinel节点监控 127.0.0.1 7001 这个主节点 # 2：表示主节点失败至少需要2个Sentinel节点同意 sentinel down-after-milliseconds mymaster 30000 # 每个Sentinel节点都要定期发PING命令来判断Redis数据节点和其余Sentinel节点是否可达 # 这里配置为30000毫秒，即超过30秒未收到某个节点的PING命令且未收到回复，则判定不可达 sentinel parallel-syncs mymaster 1 # 当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点 # 原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1 sentinel failover-timeout mymaster 180000 # 设定故障转移的超时时间为180000毫秒
27002.conf、27003.conf的配置与上面的配置(27001.conf)差异仅在于端口.
启动哨兵：redis-sentinel 配置文件
启动后，哨兵的配置文件会被重写入sentinel myid等信息.
验证哨兵集群
[root@fedora conf]# redis-cli -p 27001 info sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=127.0.0.1:7003,slaves=2,sentinels=3 # 看到最后一条信息即正确配置了哨兵集群 # name=mymaster -> 哨兵别名 # status=ok -> 状态OK # address=127.0.0.1:7003 -> 监控的地址 # slaves=2 -> 当前有2个从节点 # sentinels=3 -> 当前共有3个哨兵
到这里，哨兵集群已经搭建完毕了.
不用说，此时你肯定是想去干掉主节点了吧，先别慌，我们来看看下面的监控扩扑图.
监控扩扑图
验证故障转移的大致思路
- 干掉主节点的Redis进程7001端口，等待
down-after-milliseconds配置的时间后，观察从节点是否会进行新的master选举，进行切换.- 重新恢复旧的“master”节点，查看此时的redis身份.