这篇文章主要介绍Redis高可用架构 Redis Sentinel，分别从它是什么，为什么使用，自动化过程以及部署等几个方面说明。
Redis Sentinel 是什么？
Redis Sentinel是Redis的高可用实现方案，是一个分布式架构，包含了若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其他Sentinel节点进行监控，当发现节点不可用时，程序会进行自动化处理，不需要人工介入，从而高效解决了Redis的高可用问题。
为什么要使用？
传统的主从复制模式将主节点数据改变同步给从节点，这样作用有两个：
作为主节点出现故障的备份
降低主节点的「读」压力
在主从复制模式下，一旦主节点出现故障，这个过程中需要人工干预进行故障转移，由于人工干预实时性无法得到保证，并且操作过程也容易出现错误，增加了整个过程的不便。所以需要引入一个高可用的架构来自动化转移的整个过程。
自动化过程
转移过程同主从复制人工干预逻辑一样，这里面我们先看人工干预过程：
主节点(M)故障，从节点(S1,S2)复制中断。
执行
slaveof no one选一个S1从节点作为新节点。更新客户端redis链接到新的主节点S1，重启
从节点S2开始复制主节点S1数据，等待曾经的主节点M恢复，去复制新的主节点S1数据。
Redis sentinel和主从模式区别只是增加Sentinel节点进行Redis节点监控。
如图每个Sentinel节点通过定时监控发现主节点出现故障（主关下线）
多个Sentinel节点对主节点故障达成一致，选出一个领导者负责故障转移
转移数据过程同上面「人工干预」逻辑一致，只是是自动化的。
转移完成后，节点slave-1（或者slave-2）变为主节点，原来的master 变为从节点
从上面看出Redis Sentinel具有监控通知，主节点故障转移，提供配置（客户端连接Sentinel节点）等功能。
部署上线
这里我们部署架构使用3个Sentinel节点，1个主节点，2个从节点，组成Redis Sentinel架构。
首先我们正常启动master，slave节点
配置sentinel conf 文件
配置文件redis_sentinel.conf如下：
port 26379
bind 10.xx.xx.xx
sentinel monitor mymaster 10.xx.xx.xx 6379 2
# 表示配置需要监控10.xx.xx.xx:6379
# 2表示至少需要2个Sentinel节点统一，
# mymaster是主节点别名，防止挂了也可以找到主节点
sentinel auth-pass mymaster password # 需要的密码
sentinel config-epoch mymaster 0 #确认mymater SDOWN时长
sentinel down-after-milliseconds mymaster 5000
# mymaster多久不响应认为SDOWN
sentinel failover-timeout mymaster 60000
# 2次failover切换时间
dir "/etc/redis" # 定义目录存放
daemonize yes
pidfile "/var/run/redis/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"做service启动脚本redis-sentinel.sh放在
/etc/init.d/并且该脚本可执行
sudo service redis-sentinel start
一些建议
Redis Sentinel的所有节点应该分布在不同的物理机上。
部署至少三个且奇数个的Sentinel节点
客户端连接到sentinel节点上。