Redis Sentinel

主从复制高可用？

首先回顾一下主从复制，主要有两个作用，第一为主节点提供数据备份，当主节点宕机时，从节点会有数据的完整副本。第二个就是为主节点提供读的分流，实现读写分离，可以减轻主节点的压力。
但是呢单使用主从复制模型会存在以下问题：

1. 手动故障转移
   就是一旦主节点出现故障，那么故障转移基本上是需要手工来完成的。
2. 写能力和存储能力受限
   写只能写在一个节点上，而且存储也是在一个节点上进行存储。

主从复制-master宕掉

如图为一主两从模型，当master发生宕机时，那么复制也必然断掉了，而从节点与主节点的连接肯定也是失败的，这样数据的读取是正常的，但是数据的更新就无法保障了。

主从复制-master宕掉故障处理

首先要选择一个slave执行命令 slave no one，使其成为master节点。然后对其余的slave执行 slaveof new master，这样就完成了新的master节点以及其从节点的构建过程。同时需要让客户端的写操作在新的master上进行。

整个过程都是完全手工进行的，即使不手工而采用编写脚本的方式，让脚本不断监控master是否有问题，有问题之后选择一个新的master，然后让其他的slave都指向新的master节点，最后再去迁移所有的客户端。单独写这么一个完美的组件，也是非常困难的。

为了弥补主从模型在高可用方面的不足，Redis为我们提供了 Redis Sentinel 这样一个高可用的实现。

Redis Sentinel架构

故障转移处理

1. 多个sentinel发现并确认master有问题
2. 选举出一个sentinel作为领导
3. 选出一个slave作为master
4. 通知其余slave成为新的master的slave
5. 通知客户端主从变化
6. 等待老的master复活成为新master的slave

配置与安装

1. 配置开启主从节点
2. 配置开启sentinel监控主节点。(sentinel是特殊的redis)
3. 实际应该多机器
4. 详细配置节点

配置

port $(port]
dir "/usr/local/redis/data/"
logfile "$(port).log"
sentinel monitor mymaster 127.0.0.1 7000 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000