一、简介:
1、Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance),该系统执行以下三个任务:
1)监控(Monitoring):Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
2)提醒(Notification):当被监控的某个 Redis 服务器出现问题时,Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
3)自动故障迁移(Automatic failover):当一个主服务器不能正常工作时,Sentinel 会开始一次自动故障迁移操作,它会将失效主服务器的其中一个从服务器升级为新的主服务器,并让失效主服务器的其他从服务器改为复制新的主服务器;当客户端试图连接失效的主服务器时,集群也会向客户端返回新主服务器的地址,使得集群可以使用新主服务器代替失效服务器。
2、Redis Sentinel 是一个分布式系统,你可以在一个架构中运行多个 Sentinel 进程(progress),这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个从服务器作为新的主服务器。
虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器,你可以在启动一个普通 Redis 服务器时通过给定 –sentinel 选项来启动 Redis Sentinel 。
Redis Sentinel 兼容 Redis 2.4.16 或以上版本,推荐使用 Redis 2.8.0 或以上的版本。
二、启动 Sentinel
方式一:使用sentinel可执行文件 redis-sentinel 程序来启动 Sentinel 系统,命令如下:
redis-sentinel /path/to/sentinel.conf
方式二:sentinel只是运行在特殊模式下的redis服务器,你可以用启动redis服务的命令来启动一个运行在 Sentinel 模式下的 Redis 服务器:
redis-server /path/to/sentinel.conf --sentinel
启动 Sentinel 实例必须指定相应的配置文件,系统会使用配置文件来保存 Sentinel 的当前状态,并在 Sentinel 重启时通过载入配置文件来进行状态还原。
Redis 源码中包含了一个名为 sentinel.conf 的文件,这个文件是一个带有详细注释的 Sentinel 配置文件示例,与 redis.conf 配置文件同目录。
三、配置 Sentinel
运行一个 Sentinel 所需的示例配置如下所示:
1、port 26379
2、dir /usr/local/redis/sentinel
3、daemonize yes
4、logfile "/usr/local/redis/sentinel/log/sentinel.log"
5、sentinel monitor mymaster 127.0.0.1 6379 2
6、sentinel down-after-milliseconds mymaster 5000
7、sentinel failover-timeout mymaster 180000
8、sentinel parallel-syncs mymaster 1
9、sentinel notification-script mymaster /var/redis/notify.sh
1、port :当前 Sentinel服务运行的端口
2、dir : Sentinel服务运行时使用的临时文件夹,默认为 /tmp
3、设置sentinel后台运行,即以守护进程的方式运行
4、设置sentinel的日志输出文件
5、sentinel monitor mymaster 127.0.0.1 6379 2 : Sentinel去监视一个名为 mymaster 的主redis实例,它的IP地址为127.0.0.1 ,端口号为 6379 ,而将这个主实例判断为失效至少需要 2 个 Sentinel进程的同意,只要同意Sentinel的数量不达标,自动failover(故障转移)就不会执行。
6、sentinel down-after-milliseconds mymaster 5000 : 指定了Sentinel认为Redis实例已经失效所需的毫秒数。 当实例超过该时间没有返回PING,或者直接返回错误,那么Sentinel将这个实例标记为主观下线。只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移:只有在足够数量的Sentinel都将一个实例标记为主观下线之后,实例才会被标记为客观下线,这时自动故障迁移才会执行。
7、sentinel failover-timeout mymaster 180000 :如果在该时间(ms)内未能完成failover操作,则认为该failover失败。
8、sentinel parallel-syncs mymaster 1 :指定了在执行故障转移时,最多可以有多少个从Redis实例在同步新的主实例,在从Redis实例较多的情况下这个数字越小,同步的时间越长,完成故障转移所需的时间就越长
9、sentinel notification-script : 指定sentinel检测到该监控的redis实例指向的实例异常时,调用的报警脚本。该配置项可选,但是很常用
运行一个 Sentinel 所需的最少配置如下所示:
sentinel monitor mymaster 127.0.0.1 6379 1
注意:sentinel启动之后,会把默认配置以及非官方配置(比如设置守护进程与日志输出的配置)注释,并会重写sentinel.conf配置,启动之后可以看看配置文件的变化,重启的时候一定要关注此时配置,很可能与之前预想的配置不一样了
四、主观下线与客观下线概念
主观下线(Subjectively Down, 简称 SDOWN)指的是单个 Sentinel 实例对服务器做出的下线判断。
客观下线(Objectively Down, 简称 ODOWN)指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的服务器下线判断。(一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。)
五、自动发现 Sentinel 和从服务器
1、发现其它的sentinel:
一个 Sentinel 可以与其他多个 Sentinel 进行连接,各个 Sentinel 之间可以互相检查对方的可用性,并进行信息交换。
你无须为运行的每个 Sentinel 分别设置其他 Sentinel 的地址,因为 Sentinel 可以通过发布与订阅功能来自动发现正在监视相同主服务器的其他 Sentinel ,这一功能是通过向频道 sentinel:hello 发送信息来实现的。
2、发现从服务器:
与此类似,你也不必手动列出主服务器属下的所有从服务器,因为 Sentinel 可以通过询问主服务器来获得所有从服务器的信息。
六、sentinel运行机制
每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。
如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值,那么这个实例会被 Sentinel 标记为主观下线。
一个有效回复可以是: +PONG 、 -LOADING 或者 -MASTERDOWN 。
如果一个主服务器被标记为主观下线,那么正在监视这个主服务器的所有 Sentinel 要以每秒一次的频率确认主服务器的确进入了主观下线状态。
如果一个主服务器被标记为主观下线,并且有足够数量的 Sentinel (至少要达到配置文件指定的数量)在指定的时间范围内同意这一判断,那么这个主服务器被标记为客观下线。
在一般情况下,每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。
当一个主服务器被 Sentinel 标记为客观下线时,Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
当没有足够数量的 Sentinel 同意主服务器已经下线,主服务器的客观下线状态就会被移除。当主服务器重新向 Sentinel 的 PING 命令返回有效回复时,主服务器的主管下线状态就会被移除。
出现故障的服务器重新启动,sentinel将其作为slave分配给前面重新选定的master。
配置文件的变化:所有slave的redis.conf中的slaveof被重写,sentinel.conf配置监控的主服务也会被替换