redis主从复制作用
1 可以提供数据副本
2 可以拓展读性能，进行读写分离等
redis主从复制存在的问题
但是redis主从复制也有无法解决的问题
1 无法进行自动故障转移
2 主节点磁盘和QPS瓶颈
第一个可以通过Redis官方的高可用方案Redis Sentinel解决。
第二个问题可以通过Redis Cluster解决。集群以后再说，今天主要介绍一下Redis Sentinel的原理与安装
Redis Sentinel简介
Redis Sentinel是Redis官方的高可用性（High Availablility）解决方案
Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：
监控（Monitoring）：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。
虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个运行在特殊模式下的 Redis 服务器， 你可以在启动一个普通 Redis 服务器时通过给定 –sentinel 选项来启动 Redis Sentinel 。
更多信息参考官方文档 ：http://www.redis.cn/topics/sentinel.html
Redis Sentine搭建
为方便演示，所有主从节点和sentinel节点都部署在一台服务器上，根据端口区分进程或角色，并且配置文件从简。生产中不能这样做。
| 节点角色 | ip | port |
| master | 10.238.162.34 | 6379 |
| salve1 | 10.238.162.34 | 6380 |
| salve2 | 10.238.162.34 | 6381 |
| sentinel1 | 10.238.162.34 | 26379 |
| sentinel2 | 10.238.162.34 | 26380 |
| sentinel3 | 10.238.162.34 | 26381 |
架构图
1 部署Redis主从节点
主从节点配置文件
#redis-6379.conf 主节点
daemonize yes
port 6379
logfile "6379.log"
dir /server/redis_data
dbfilename dump-6379.rdb
#redis-6380.conf 从节点
daemonize yes
port 6380
logfile "6380.log"
dir /server/redis_data
slaveof 10.238.162.34 6379
slave-read-only yes
#redis-6381.conf 从节点
daemonize yes
port 6381
logfile "6381.log"
dir /server/redis_data
slaveof 10.238.162.34 6379
slave-read-only yes
启动主从节点
redis-server /usr/local/redis/config/redis-6379.conf
redis-server /usr/local/redis/config/redis-6380.conf
redis-server /usr/local/redis/config/redis-6381.conf 查看主从节点复制
[root@localhost config]# redis-cli -p 6379 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=10.238.162.34,port=6380,state=online,offset=1281344,lag=0
slave1:ip=10.238.162.34,port=6381,state=online,offset=1281203,lag=1
master_repl_offset:1281344
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:232769
repl_backlog_histlen:10485762 部署哨兵节点
可以通过以下方法从sentinel配置文件模板中获取一份无注释无空行的最简配置模板：
cat sentinel.conf |grep -v "#" |grep -v "^$" > sentinel-26379.conf
其他两个sentinel节点配置文件只有端口号不同，其余内容相同。
port 26379
daemonize yes
dir "/server/redis_data"
logfile "26379.log"
sentinel monitor mymaster 10.238.162.34 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
参数解释
- sentinel monitor mymaster 10.238.162.34 6379 2指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址为 10.238.162.34， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。
不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移， 并预留一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号）。
换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执行自动故障迁移的。
其他选项的基本格式如下：
sentinel <选项的名字> <主服务器的名字> <选项的值>
各个选项的功能如下：
- down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称 SDOWN ）。
不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。
将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
- parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。
如果从服务器被设置为允许使用过期数据集（参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明）， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。
你可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状态。
示例配置文件 sentinel.conf 也对相关的选项进行了完整的注释。
启动sentinel节点，有两种方式，我们以第一种方式启动。
redis-sentinel /etc/sentinel.conf
redis-server /etc/sentinel.conf --sentinel
redis-sentinel sentinel-26379.conf
redis-sentinel sentinel-26381.conf
redis-sentinel sentinel-26380.conf 查看sentinel获取到的信息，sentinel可以自动获取master下的slave节点信息，并且sentinel之间也可以相互感知到。
[root@localhost config]# redis-cli -p 26379 info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=10.238.162.34:6379,slaves=2,sentinels=33 故障转移演示
Step1 手动killredis主节点，模拟服务器宕机等故障
Step2 如果此时立即在哨兵节点中使用info Sentinel命令查看，会发现主节点还没有切换过来，因为哨兵发现主节点故障并转移，需要一段时间，配置文件中为30秒。
一段时间以后，再次在哨兵节点中执行info Sentinel查看，发现主节点已经切换成6381节点。
但是同时可以发现，哨兵节点认为新的主节点仍然有2个从节点，这是因为哨兵在将6381切换成主节点的同时，将6379节点置为其从节点；虽然6379从节点已经挂掉，但是由于哨兵并不会对从节点进行客观下线，因此认为该从节点一直存在。当6379节点重新启动后
Step3 查看节点日志
6381从节点日志
a. 6381从节点与6379主节点失联，同步失败
b. 尝试30秒后开始故障转移（因为配置文件是30秒后启动故障转移）
c. 6381接受一条用户请求，变为主节点，配置文件改写
d. 6380要求成为6381的从节点，并开始后台数据同步。
e.6380数据同步成功
....
26379 哨兵节点日志
Step4 重启启动6379节点
redis-server redis-6379.conf
配置文件改写并成为6381的从
