最近研究了redis的集群方案，第一个方案是创建 redis cluster，第二种方案就是用哨兵模式来进行主从替换以及故障恢复。
一、sentinel介绍
Redis Sentinel
Sentinel(哨兵)是用于监控redis集群中Master状态的工具，其已经被集成在redis2.4+的版本中。
Sentinel作用：
1)：Master状态检测 2)：如果Master异常，则会进行Master-Slave切换，将其中一个Slave作为Master，将之前的Master作为Slave 3)：Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换
Sentinel工作方式：
1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令 2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。 3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。 4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除
主观下线和客观下线：
主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。 客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.
通俗来讲就是：
redis的sentinel系统用来管理多个redis服务器，可以实现一个功能上实现HA的集群。该系统主要执行四个任务：
①监控（ Monitoring ）： Redis Sentinel实时监控主服务器和从服务器运行状态。 ②提醒（notification）： 当被监控的某个 Redis 服务器出现问题时， Redis Sentinel 可以向系统管理员发送通知， 也可以通过 API 向其他程序发送通知。 ③自动故障转移：如果一个master不正常运行了，哨兵可以启动一个故障转移进程，将一个slave升级成为master，其他的slave被重新配置使用新的master，并且应用程序使用Redis服务端通知的新地址。 ④配置提供者：哨兵作为Redis客户端发现的权威来源：客户端连接到哨兵请求当前可靠的master的地址。如果发生故障，哨兵将报告新地址。
二、搭建redis-sentinel 集群环境
0、安装redis
操作系统：CentOS6.5 wget http://download.redis.io/releases/redis-3.2.1.tar.gz tar -xzf redis-3.2.1.tar.gz cd redis-3.2.1 yum -y install gcc make [MALLOC=libc] make install 或者 make PREFIX=/usr/local/redis install #默认安装位置为/usr/local/bin echo "export PATH=/usr/local/redis/bin:$PATH" >> /etc/profile.d/redis.sh source /etc/profile.d/redis.sh
1、在/usr/local/ 下新建一个目录redis-sentinel，然后在此目录下新建7501/ 7502/ 7503/ 7504/ 7505/ 7506/ 7507/七个目录。
mkdir /usr/local/redis-sentinel
mkdir /usr/local/redis-sentinel/{7501,7502,7503,7504,7505,7506,7507}
2、将redis安装目录下的reids.conf，拷贝到前4个目录下，分别命名为：redis-7501.conf redis-7502.conf redis-7503.conf redis-7504.conf
cp /root/redis-3.2.1/redis.conf /usr/local/redis-sentinel/7501/redis-7501.conf cp /root/redis-3.2.1/redis.conf /usr/local/redis-sentinel/7502/redis-7502.conf cp /root/redis-3.2.1/redis.conf /usr/local/redis-sentinel/7503/redis-7503.conf cp /root/redis-3.2.1/redis.conf /usr/local/redis-sentinel/7504/redis-7504.conf
修改配置文件内容（以redis-7501.conf为例）：
daemonize yes pidfile /var/run/redis_7501.pid port 7501 bind 10.10.172.191 #可选，默认就处理所有请求。 logfile "./redis-7501.log" dir "/usr/local/redis-sentinel/7501" redis配置密码的话，需要以下配置 masterauth "123456" requirepass "123456" appendonly yes
3、 将redis安装目录下的sentinel.conf拷贝到7505/ 7506/和7507/目录下分别命名： sentinel-7505.conf sentinel-7506.conf sentinel-7507.conf
cp /root/redis-3.2.1/sentinel.conf /usr/local/redis-sentinel/7505/sentinel-7505.conf cp /root/redis-3.2.1/sentinel.conf /usr/local/redis-sentinel/7506/sentinel-7506.conf cp /root/redis-3.2.1/sentinel.conf /usr/local/redis-sentinel/7507/sentinel-7507.conf
修改配置文件(以sentinel-7505.conf为例)：
daemonize yes port 7505 #指定工作目录 dir "/usr/local/redis-sentinel/7505"no logfile "./sentinel.log" #指定别名 主节点地址 端口 哨兵个数（有几个哨兵监控到主节点宕机执行转移） sentinel monitor mymaster 10.10.172.191 7501 2 #如果哨兵3s内没有收到主节点的心跳，哨兵就认为主节点宕机了，默认是30秒 sentinel down-after-milliseconds mymaster 3000 #选举出新的主节点之后，可以同时连接从节点的个数 sentinel parallel-syncs mymaster 1 #如果10秒后,master仍没活过来，则启动failover,默认180s sentinel failover-timeout mymaster 10000 #配置连接redis主节点密码 sentinel auth-pass mymaster 123456 注：我们稍后要启动四个redis实例，其中端口为7501的redis设为master，其他三个设为slave 。所以mymaster 后跟的是master的ip和端口，最后一个'2'代表我要启动只要有2个sentinel认为master下线，就认为该master客观下线，启动failover并选举产生新的master。通常最后一个参数不能多于启动的sentinel实例数。建议至少启动三台sentinel实例。
4、启动redis和sentinel
分别启动4个redis实例：
redis-server /usr/local/redis-sentinel/7501/redis-7501.conf redis-server /usr/local/redis-sentinel/7502/redis-7502.conf redis-server /usr/local/redis-sentinel/7503/redis-7503.conf redis-server /usr/local/redis-sentinel/7504/redis-7504.conf
然后分别登陆7502 7503 7504三个实例，动态改变主从关系，成为7501的slave:
redis-cli -h 10.10.172.191 -p 7502 10.10.172.191:7502> SLAVEOF 10.10.172.191 7501 #这里也可以事先直接修改从实例redis文件追加slaveof 10.10.172.191 6379
查看主从状态：
10.10.172.191:7501> info replication # Replication role:master connected_slaves:3 slave0:ip=10.10.172.191,port=7502,state=online,offset=127,lag=0 slave1:ip=10.10.172.191,port=7503,state=online,offset=127,lag=0 slave2:ip=10.10.172.191,port=7504,state=online,offset=127,lag=1 master_repl_offset:127 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:126 注：从库末尾会自动添加同步语句slaveof 10.10.172.191 7501。
以后台启动模式启动两个sentinel（哨兵）:
redis-sentinel /usr/local/redis-sentinel/7505/sentinel-7505.conf redis-sentinel /usr/local/redis-sentinel/7506/sentinel-7506.conf redis-sentinel /usr/local/redis-sentinel/7507/sentinel-7507.conf
查看redis进程状态
[root@localhost ~]# ps -ef|grep redis root 2121 1 0 10:11 ? 00:00:00 redis-server 10.10.172.191:7501 root 2125 1 0 10:11 ? 00:00:00 redis-server 10.10.172.191:7502 root 2129 1 0 10:11 ? 00:00:00 redis-server 10.10.172.191:7503 root 2133 1 0 10:11 ? 00:00:00 redis-server 10.10.172.191:7504 root 2156 1 0 10:15 ? 00:00:00 redis-sentinel *:7505 [sentinel] root 2160 1 0 10:15 ? 00:00:00 redis-sentinel *:7506 [sentinel] root 2164 1 0 10:15 ? 00:00:00 redis-sentinel *:7507 [sentinel] root 2169 1858 0 10:16 pts/0 00:00:00 grep redis
5、sentinel一些命令介绍
要使用sentinel的命令，我们需要用redis-cli命令进入到sentinel： redis-cli -h 10.10.172.191 -p 7505 -a 123456 ①INFO sentinel的基本状态信息 ②SENTINEL masters | SENTINEL master mymaster 列出所有被监视的主服务器，以及这些主服务器的当前状态 ③ SENTINEL slaves mymaster 列出给定主服务器的所有从服务器，以及这些从服务器的当前状态 ④SENTINEL get-master-addr-by-name mymaster 返回给定名字的主服务器的 IP 地址和端口号 ⑤SENTINEL reset 重置所有名字和给定模式 pattern 相匹配的主服务器。重置操作清除主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器和 Sentinel 。 ⑥SENTINEL failover 当主服务器失效时， 在不询问其他 Sentinel 意见的情况下， 强制开始一次自动故障迁移，但是它会给其他sentinel发送一个最新的配置，其他sentinel会根据这个配置进行更新.
6、测试：
（1）登陆到 master：
# redis-cli -h 10.10.172.191 -p 7501 -a 123456 10.10.172.191:7501> info Replication #列出Master的信息 10.10.172.191:7501> set name "zhangsan" # redis-cli -h 10.10.172.191 -p 7502 10.10.172.191:7502> get name "zhangsan" 10.10.172.191:7502> set age 24 (error) READONLY You can't write against a read only slave.
可以看到：我们的主从模式中，slave默认是只读。
（2）目前7501是master, 我们强制kill掉 7501 的进程以后，查看sentinel打出的日志信息：
# tail -fn 10 /usr/local/redis-sentinel/7505/sentinel.log 2156:X 28 Mar 10:25:54.960 # +new-epoch 2 2156:X 28 Mar 10:25:54.962 # +vote-for-leader a786b1a5a73cc8251ce888704024a14e417e33af 2 2156:X 28 Mar 10:25:54.992 # +odown master mymaster 10.10.172.191 7501 #quorum 3/2 2156:X 28 Mar 10:25:54.992 # Next failover delay: I will not start a failover before Wed Mar 28 10:26:15 2018 2156:X 28 Mar 10:25:56.037 # +config-update-from sentinel 10.10.172.191:7507 10.10.172.191 7507 @ mymaster 10.10.172.191 7501 2156:X 28 Mar 10:25:56.037 # +switch-master mymaster 10.10.172.191 7501 10.10.172.191 7502 2156:X 28 Mar 10:25:56.037 * +slave slave 10.10.172.191:7504 10.10.172.191 7504 @ mymaster 10.10.172.191 7502 2156:X 28 Mar 10:25:56.037 * +slave slave 10.10.172.191:7503 10.10.172.191 7503 @ mymaster 10.10.172.191 7502 2156:X 28 Mar 10:25:56.037 * +slave slave 10.10.172.191:7501 10.10.172.191 7501 @ mymaster 10.10.172.191 7502 2156:X 28 Mar 10:25:59.085 # +sdown slave 10.10.172.191:7501 10.10.172.191 7501 @ mymaster 10.10.172.191 7502
可以看到，sentinel已经将7502这个redis instance提升为新的master，稍后将7501这个实例启动，动态作为7501的slave，这样就手动恢复了redis 集群。同时也在redis-7501.conf文件末尾看到主从同步配置语句“slaveof 10.10.172.191 7502”。
停止并启动实例7501 kill -9 2121 redis-server /usr/local/redis-sentinel/7501/redis-7501.conf 查看当前redis主从状态 [root@localhost ~]# redis-cli -h 10.10.172.191 -p 7505 10.10.172.191:7505> 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.10.172.191:7502,slaves=3,sentinels=3 连接redis主实例查看主从状态并创建key [root@localhost ~]# redis-cli -h 10.10.172.191 -p 7502 -a 123456 10.10.172.191:7502> info replication # Replication role:master connected_slaves:3 slave0:ip=10.10.172.191,port=7504,state=online,offset=58539,lag=1 slave1:ip=10.10.172.191,port=7503,state=online,offset=58819,lag=0 slave2:ip=10.10.172.191,port=7501,state=online,offset=58679,lag=0 master_repl_offset:58959 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:58958 10.10.172.191:7502> keys * 1) "name" 10.10.172.191:7502> set age 24 OK 10.10.172.191:7502> exit redis从实例上查看key [root@localhost ~]# redis-cli -h 10.10.172.191 -p 7501 -a 123456 10.10.172.191:7501> keys * 1) "name" 2) "age" 10.10.172.191:7501> get age "24"
7、开机自动启动redis和sentinel：
将以下代码追加到/etc/rc.local文件末尾 /usr/local/bin/redis-server /usr/local/redis-sentinel/7501/redis-7501.conf /usr/local/bin/redis-server /usr/local/redis-sentinel/7502/redis-7502.conf /usr/local/bin/redis-server /usr/local/redis-sentinel/7503/redis-7503.conf /usr/local/bin/redis-server /usr/local/redis-sentinel/7504/redis-7504.conf /usr/local/bin/redis-sentinel /usr/local/redis-sentinel/7505/sentinel-7505.conf /usr/local/bin/redis-sentinel /usr/local/redis-sentinel/7506/sentinel-7506.conf /usr/local/bin/redis-sentinel /usr/local/redis-sentinel/7507/sentinel-7507.conf
总结：当master宕机之后，sentinel会把一个slave 升级成master,当master恢复正常，原来的master自动切换成slave，不会自动恢复成master，当slave中的任意节点宕机，sentinel自动剔除。
sentinel.conf配置文件详解
# Example sentinel.conf # 哨兵sentinel实例运行的端口 默认26379 port 26379 # 哨兵sentinel的工作目录 dir /tmp # 哨兵sentinel监控的redis主节点的 ip port # master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。 # quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了 # sentinel monitorsentinel monitor mymaster 127.0.0.1 6379 2 # 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码 # 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码 # sentinel auth-pass sentinel auth-pass mymaster MySUPER--secret-0123passw0rd # 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒 # sentinel down-after-milliseconds sentinel down-after-milliseconds mymaster 30000 # 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步， 这个数字越小，完成failover所需的时间就越长， 但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。 # 可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。 # sentinel parallel-syncs sentinel parallel-syncs mymaster 1 # 故障转移的超时时间 failover-timeout 可以用在以下这些方面： #1. 同一个sentinel对同一个master两次failover之间的间隔时间。 #2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。 #3.当想要取消一个正在进行的failover所需要的时间。 #4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了 # 默认三分钟 # sentinel failover-timeout sentinel failover-timeout mymaster 180000 # SCRIPTS EXECUTION #配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。 #对于脚本的运行结果有以下规则： #若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10 #若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。 #如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。 #一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。 #通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本， 这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数， 一个是事件的类型， 一个是事件的描述。 如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。 #通知脚本 # sentinel notification-script sentinel notification-script mymaster /var/redis/notify.sh # 客户端重新配置主节点参数脚本 # 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。 # 以下参数将会在调用脚本时传给脚本: # # 目前 总是“failover”, # 是“leader”或者“observer”中的一个。 # 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的 # 这个脚本应该是通用的，能被多次调用，不是针对性的。 # sentinel client-reconfig-script sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
Sentinel模式下的几个事件
· +reset-master ：主服务器已被重置。 · +slave ：一个新的从服务器已经被 Sentinel 识别并关联。 · +failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。 · +failover-detected ：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。 · +slave-reconf-sent ：领头（leader）的 Sentinel 向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令，为实例设置新的主服务器。 · +slave-reconf-inprog ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。 · +slave-reconf-done ：从服务器已经成功完成对新主服务器的同步。 · -dup-sentinel ：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。 · +sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。 · +sdown ：给定的实例现在处于主观下线状态。 · -sdown ：给定的实例已经不再处于主观下线状态。 · +odown ：给定的实例现在处于客观下线状态。 · -odown ：给定的实例已经不再处于客观下线状态。 · +new-epoch ：当前的纪元（epoch）已经被更新。 · +try-failover ：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。 · +elected-leader ：赢得指定纪元的选举，可以进行故障迁移操作了。 · +failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。 · no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。 · selected-slave ：Sentinel 顺利找到适合进行升级的从服务器。 · failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。 · failover-end-for-timeout ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。 · failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。 · +switch-master ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。 · +tilt ：进入 tilt 模式。 · -tilt ：退出 tilt 模式。