当前位置： 主页> > 案例中心>

Redis Sentinel集群部署

日期：2016-09-13 13:33:48 / 人气： 7600

Redis Sentinel集群部署

什么是Redis Sentinel

Redis Sentinel是用来实现Redis高可用的一套解决方案。Redis Sentinel由两个部分组成：由一个或者多个Sentinel实例组成Sentinel系统；由一个主Redis服务器(Master Redis)和多个从Redis服务器(Slave Redis)组成主从备份的Redis系统。

Sentinel系统本身是一个分布式的系统，它的作用是监视Redis服务器，在Master Redis下线时，自动将某个Slave Redis提升为新的主服务器。Redis系统由Master Redis处理客户端的命令请求，Slave Redis作为主服务器的备份而存在。

Redis Sentinel主要作用

  • 监控(Monitoring)：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

  • 提醒(Notification)：当被监控的某个Redis服务器出现问题时， Sentinel可以通过API向管理员或者其他应用程序发送通知。

  • 自动故障迁移(Automatic failover)：当一个主服务器不能正常工作时， Sentinel会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

Redis Sentinel系统架构图

Sentinel的原理并不复杂:

  • 启动N个Sentinel实例，这些Sentinel实例会去监控你指定的Redis Master/Slaves。

  • 当Redis Master节点挂掉后，Sentinel实例通过ping检测失败发现这种情况就认为该节点进入 SDOWN状态，也就是检测的Sentinel实例主观地(Subjectively)认为该Redis Master节点挂掉。

  • 当一定数目(Quorum参数设定的Sentinel实例都认为该Master挂掉的情况下，该节点将转换进入ODOWN状态，也就是客观地(Objectively)挂掉的状态。

  • 接下来Sentinel实例之间发起选举，选择其中一个Sentinel实例发起failover过程：从Slave中选择一台作为新的Master，让其它Slave从新的Master复制数据，并通过Pub/Sub发布事件。

  • 使用者客户端从任意Sentinel实例获取Redis配置信息，并监听(可选)Sentinel发出的事件： SDOWN, ODOWN以及failover等，并做相应主从切换，Sentinel还扮演了服务发现的角色。

  • Sentinel的Leader选举采用的是Raft协议。

构建Redis Sentinel集群

Redis Sentinel环境准备

主机名 IP 端口号 角色
dev-master-01 192.168.2.210 6379/26379 Redis Master/Sentinel
dev-node-01 192.168.2.211 6379/26379 Redis Master/Sentinel
dev-node-02 192.168.2.212 6379/26379 Redis Master/Sentinel

一个一主多从的Redis系统中，可以使用多个Sentinel进行监控任务以保证系统足够稳健。此时，不仅Sentinel会同时监控主数据库和从数据库，Sentinel之间也会相互监控。在这里，建议大家Sentinel至少部署三个，并且使用奇数个Sentinel。

安装Redis和Sentinel

在三台服务器上分别安装Redis和Sentinel。需要注意的是，如果要给Redis设置密码，需要在三个Redis的配置文件中设置相同的密码。

安装的Redis版本必须在2.8版本以上。

$ apt-get install redis-server redis-sentinel

配置Redis和Sentinel

配置Redis

三台Redis主机配置类似，只是初次配置时角色不同。这里以主机dev-master-01为例，其它两台按实际情况修改就行了。

Redis默认会绑定到127.0.0.1，这里要在多台机器间通信，我们将它绑定到主机IP上。

$ vim /etc/redis/redis.conf
bind 192.168.2.210

如果要给Redis设置密码，需要在三个Redis的配置文件中设置相同的密码。

$ vim /etc/redis/redis.conf
requirepass "000000"

设置主从复制

在两个Slave Redis的配置文件中声明所从属的主数据库。

$ vim /etc/redis/redis.conf
slaveof 192.168.2.210 6379

这里需要注意一点：当一个Master配置需要密码才能连接时，客户端和Slave在连接时都需要提供密码。Master通过requirepass设置自身的密码，不提供密码无法连接到这个Master。Slave通过masterauth来设置访问Master时的密码。

Sentinel可以切换主从数据库，主数据库可能会变成从数据库，所以三台机器上都需要同时设置requirepass和masterauth配置项。

$ vim /etc/redis/redis.conf
requirepass "000000"
masterauth "000000"

配置Sentinel

redis-sentinel软件包中默认包含了一个名为sentinel.conf的文件，默认在/etc/redis/sentinel.conf。这里以主机dev-master-01为例，其它两台配置类似，按实际情况修改就行了。

运行一个Sentinel所需的最少配置如下所示：

$ vim /etc/redis/sentinel.conf

daemonize yes
port 26379
bind 192.168.2.210
sentinel monitor redis-master 192.168.2.210 6379 2
sentinel down-after-milliseconds redis-master 5000
sentinel failover-timeout redis-master 180000
sentinel parallel-syncs redis-master 2
sentinel auth-pass redis-master 000000
sentinel notification-script redis-master /etc/redis/notify.sh
sentinel client-reconfig-script redis-master /etc/redis/failover.sh
logfile /var/log/redis/redis-sentinel.log

以上配置项说明：

  • daemonize yes

以后台进程模式运行。

  • port 26379

Sentinel实例之间的通讯端口，该端口号默认为26379。

  • bind 192.168.2.210

Sentinel默认会绑定到127.0.0.1，这里要在多台机器间通信，我们将它绑定到主机IP上。

  • sentinel monitor redis-master 192.168.2.210 6379 2

Sentinel去监视一个名为redis-master的主服务器，这个主服务器的IP地址为192.168.2.210 ，端口号为6379。将这个主服务器判断为失效至少需要2个Sentinel同意，一般设置为N/2+1(N为Sentinel总数)。只要同意Sentinel的数量不达标，自动故障迁移就不会执行。

不过要注意，无论你设置要多少个Sentinel同意才能判断一个服务器失效， 一个Sentinel都需要获得系统中多数Sentinel的支持，才能发起一次自动故障迁移，并预留一个给定的配置纪元。(configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本号)。

  • sentinel down-after-milliseconds redis-master 5000

down-after-milliseconds选项指定了Sentinel认为服务器已经断线所需的毫秒数。如果服务器在给定的毫秒数之内，没有返回Sentinel发送的PING命令的回复，或者返回一个错误，那么Sentinel将这个服务器标记为主观下线(subjectively down，简称SDOWN)。

不过只有一个Sentinel将服务器标记为主观下线并不一定会引起服务器的自动故障迁移，只有在足够数量的Sentinel都将一个服务器标记为主观下线之后，服务器才会被标记为客观下线(objectively down，简称ODOWN)， 这时自动故障迁移才会执行。将服务器标记为客观下线所需的Sentinel数量由对主服务器的配置(sentinel monitor参数)决定。

  • sentinel failover-timeout redis-master 180000

如果在多少毫秒内没有把宕掉的那台Master恢复，那Sentinel认为这是一次真正的宕机。在下一次选取时排除该宕掉的Master作为可用的节点，然后等待一定的设定值的毫秒数后再来探测该节点是否恢复，如果恢复就把它作为一台Slave加入Sentinel监测节点群，并在下一次切换时为他分配一个”选取号”。

  • sentinel parallel-syncs redis-master 2

parallel-syncs选项指定了在执行故障转移时，最多可以有多少个从服务器同时对新的主服务器进行同步。这个数字越小，完成故障转移所需的时间就越长。

如果从服务器被设置为允许使用过期数据集(slave-serve-stale-data选项)， 那么你可能不希望所有从服务器都在同一时间向新的主服务器发送同步请求。因为尽管复制过程的绝大部分步骤都不会阻塞从服务器，但从服务器在载入主服务器发来的RDB文件时，仍然会造成从服务器在一段时间内不能处理命令请求。

如果全部从服务器一起对新的主服务器进行同步，那么就可能会造成所有从服务器在短时间内全部不可用的情况出现。你可以通过将这个值设为1来保证每次只有一个从服务器处于不能处理命令请求的状态。

  • sentinel auth-pass redis-master 000000

当Master设置了密码时，Sentinel连接Master和Slave时需要通过设置参数auth-pass配置相应密码。

  • sentinel notification-script redis-master /etc/redis/notify.sh

指定Sentinel检测到该监控的Redis实例failover时调用的报警脚本。脚本被允许执行的最大时间为60秒，超过这个时间脚本会被kill。该配置项可选，但线上系统建议配置。这里的通知脚本简单的记录一下failover事件。

# 创建通知脚本
$ vim /etc/redis/notify.sh

#! /bin/bash

echo "master failovered at `date`" > /var/log/redis/redis_issues.log
# 给脚本增加执行权限
$ chmod +x /etc/redis/notify.sh

  • sentinel client-reconfig-script redis-master /etc/redis/failover.sh

指定Sentinel failover之后重配置客户端时执行的脚本，该配置项可选，但线上系统建议配置。

  • logfile /var/log/redis/redis-sentinel.log

日志文件所在位置，默认在/var/log/redis/redis-sentinel.log。

运行Sentinel

配置完Redis和Sentinel之后，按顺序启动各个角色。启动顺序如下：Master->Slave->Sentinel，要确保按照这个顺序依次启动。

  • 启动Redis

$ systemctl start redis

  • 启动Sentinel

运行Sentinel有两种方式：

虽然Redis Sentinel有单独的软件安装包，但实际上它只是一个运行在特殊模式下的Redis实例。当前Redis Stable版已经自带了redis-sentinel这个工具。你可以在启动一个普通Redis实例时通过给定--sentinel选项来启动Redis Sentinel。

第一种：用单独的可执行文件redis-sentinel

$ redis-sentinel /etc/redis/sentinel.conf

第二种：使用redis-server的—sentinel选项