redis sentinel具有如下几个功能:
- 监控:sentinel节点会定期检测Redis数据节点、其余sentinel节点是否可达
- 通知:sentinel节点会将故障转移的结果通知给应用方
- 主节点故障转移:实现从节点晋升为主节点并维护后继的正确的主从关系
- 配置提供者:在redis sentinel结构中,客户端在初始化的时候连接的是sentinel节点集合,从中获取主节点信息
redis sentinel包含了若干个sentinel节点,这样做也带来了两个好处:
- 对于节点的故障判断是由多个sentinel节点共同完成,这样可以有效放置误判
- sentinel节点集合是由若干个sentinel节点组成,这样即使个别sentinel节点不可用,整个sentinel节点集合仍然是健壮的
但是sentinel节点本身就是独立的redis节点,只不过它们有一些特殊,它们不存储数据,只支持部分命令
安装和部署
部署拓扑结构
下面将以3个Sentinel节点、1个主节点、2个从节点组成一个Redis Sentinel为例进行部署。
部署Redis数据节点
redis sentinel的redis数据节点没有做任何特殊配置,所以直接安装普通方式直接启动即可
启动主节点
配置:
> cat redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/opt/soft/redis/data/" # 一定要预先创建这个命令
启用主节点:
./bin/redis-server redis-6379.conf
确认是否启用。一般来说只需要ping命令测试一下就可以,确认redis数据节点是否已经启用:
> ./bin/redis-cli -h 127.0.0.1 -p 6379 ping
PONG
启动两个从节点
配置: 两个从节点的配置时完全一样的,和主节点的配置不一样的是添加了slaveof配置
> redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/opt/soft/redis/data/"
slaveof 127.0.0.1 6379
> redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/opt/soft/redis/data/"
slaveof 127.0.0.1 6379
> redis-6381.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
dir "/opt/soft/redis/data/"
slaveof 127.0.0.1 6379
启动从节点:
./bin/redis-server redis-6380.conf
./bin/redis-server redis-6381.conf
验证:
$ redis-cli -h 127.0.0.1 -p 6380 ping
PONG
$ redis-cli -h 127.0.0.1 -p 6381 ping
PONG
确认主从关系
主节点视角,它有两个从节点,分别是127.0.0.1:6380和127.0.0.1:6381:
$ redis-cli -h 127.0.0.1 -p 6379 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=281,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=281,lag=0
从节点的视角,它的主节点是127.0.0.1:6379:
$ redis-cli -h 127.0.0.1 -p 6379 info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
....................
部署sentinel节点
3个Sentinel节点的部署方法是完全一致的(端口不同),下面以sentinel-1节点的部署为例进行说明。
配置sentinel节点
> redis-sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-millisenconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
- sentinel节点的默认端口是26379
sentinel monitor mymaster 127.0.0.1 6379 2
配置表示sentinel-1节点需要监控127.0.0.1:7379
这个主节点,2
表示主节点失败至少需要2个sentinel节点同意,mymaster是主节点的别名- 其他配置参考【配置优化】
启动sentinel节点
sentinel节点的启动方法有两种:
- 使用redis-sentinel命令:
redis-sentinel redis-sentinel-26379.conf
- 使用redis-server命令加–sentinel参数:
redis-server redis-sentinel-26379.conf --sentinel
两种方法本质上是一样的。
确认
sentinel节点本质上是一个特殊的节点,所以也可以通过info命令来查询它的相关信息
- 从下面info的sentinel片段来看,sentinel节点找到了主节点127.0.0.1:6379,发现了它的两个从节点,也就是说同时发现redis sentinel一共有3个sentinel节点。
- 这里只需要了解sentinel节点能够彼此感知到双方,同时能够感知到redis数据节点就可以了
$ redis-cli -h 127.0.0.1 -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_titl:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinel=3
至此Redis Sentinel已经搭建起来了,整体上还是比较容易的,但是有2点需要强调一下:
- 生存环境中建议redis sentinel的所有节点应该分布在不同的物理机器上
- redis sentinel中的数据节点和和普通的redis数据节点在配置上没有任何区别,只不过是添加了一些sentinel节点对他们进行监控
配置优化
了解每个配置的含义有助于更加合理地使用Redis Sentinel,一次本节将对每个配置的使用和优化进行详细介绍。Redis安装目录下有一个sentinel.conf,是默认的Sentinel节点配置文件,下面就以它作为例子进行说明。
配置优化和说明
port 26379
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
#sentinel auth-pass <master-name> <password>
#sentinel notification-script <master-name> <script-path>
#sentinel client-reconfig-script <master-name> <script-path>
port和dir分布代表sentinel节点的端口和工作目录。
sentinel monitor
sentinel monitor <master-name> <ip> <port> <quorum>
- Sentinel节点会定期监控主节点,所以从配置上必然也会有所体现,本配置说明Sentinel节点要监控的是一个名字叫做< master-name>,ip地址和端口为< ip> < port>的主节点
- < quorun >代表要判定主节点最终不可达所需要的票数。
- < quorum>参数用于故障发现和判定,例如将quorum配置为2,代表至少有2个Sentinel节点认为主节点不可达,那么这个不可达的判定才是客观的。对于< quorum>设置的越小,那么达到下线的条件越宽松,反之越严格。一般建议将其设置为Sentinel节点一半加一
- 同时< quorum>还与Sentinel节点的领导者选举有关,至少要有max(quorum, num(sentinels)/2 + 1)个Sentinel节点参与选举,才能选出领导者Sentinel,从而完成故障转移。例如有5个Sentinel节点,quorum=4,那么至少要有max(quorum, num(sentinels)/ 2 + 1)=4个在线Sentinel节点才可以进行领导者选举。
sentinel down-after-milliseconds
sentinel down-after-milliseconds <master-name> <times>
- 每个sentinel节点都要通过定期发送ping命令来判断redis数据节点和其余sentinel节点是否可达,如果超过了down-after-milliseconds配置的时间却没有有效的回复,则判断节点不可达,< times>(单位为毫秒)就是超时时间。这个配置是对节点时便判定的重要依据。
- 优化说明:
- down-after-milliseconds越大,代表Sentinel节点对于节点不可达的条件越宽松,反之越严格。
- 条件宽松有可能带来的问题是节点确实不可达了,那么应用方需要等待故障转移的时间越长,也就意味着应用方故障时间可能越长。
- 条件严格虽然可以及时发现故障完成故障转移,但是也存在一定的误判率。
sentinel parallel-syncs
sentinel parallel-syncs <master-name> <nums>
- 当sentinel节点集合对主节点故障判定达成一致时,sentinel领导者节点会做故障转移操作,选出新的主节点,原来的从节点会向新的主节点发起复制操作,parallel-syncs就是用来限制在一次故障转移之后,每次向新的主节点同时发起复制操作的从节点个数。
- 尽管复制操作通常不会阻塞主节点,但是同时向主节点发起复制,必然会对主节点所在的机器造成一定的网络开销和磁盘IO开销
sentinel failover-timeout
sentinel failover-timeout <master-name> <times>
- failover-timeout通常被解释成故障转移超时时间,但是实际上它作用于故障转移的各个阶段:
- 选出合适从节点
- 晋升选出的从节点为主节点
- 命令其余从节点复制新的主节点
- 等待原主节点回复后命令它去复制新的主节点
sentinel auth-pass
sentinel auth-pass <master-name> <password>
如果Sentinel监控的主节点配置了密码,sentinel auth-pass配置通过添加主节点的密码,防止Sentinel节点对主节点无法监控。
如何监控多个主节点
Redis Sentinel可以同时监控多个主节点, 具体拓扑图类似于图。配置方法也比较简单, 只需要指定多个masterName来区分不同的主节点即可, 例如下面的配置监控monitor master-business-1(10.10.xx.1: 6379) 和monitor master-business-2(10.10.xx.2: 6379) 两个主节点:
sentinel monitor master-business-1 10.10.xx.1 6379 2
sentinel down-after-milliseconds master-business-1 60000
sentinel failover-timeout master-business-1 180000
sentinel parallel-syncs master-business-1 1
sentinel monitor master-business-2 10.16.xx.2 6380 2
sentinel down-after-milliseconds master-business-2 10000
sentinel failover-timeout master-business-2 180000
sentinel parallel-syncs master-business-2 1
调整配置
和普通的Redis数据节点一样, Sentinel节点也支持动态地设置参数, 而且和普通的Redis数据节点一样并不是支持所有的参数, 具体使用方法如下:
sentinel set <param> <value>
下表为sentinel set支持的参数, 具体可以参考源码中的sentinel.c的sentinelSetCommand函数。
注意:
- sentinel set命令只对当前sentinel节点有效
- sentinel set命令如果执行成功就会立即刷新配置文件,这点和redis普通数据节点设置需要执行config rewrite刷新到配置文件不一样
- 建议所有Sentinel节点的配置尽可能一致, 这样在故障发现和转移时比较容易达成一致。
- Sentinel对外不支持config命令。
部署技巧
sentinel节点不应该部署在一台物理“机器”上
这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器, 它们虽然有不同的IP地址, 但实际上它们都是同一台物理机,同一台物理机意味着如果这台机器有什么硬件故障,所有的虚拟机都会受到影响,为了实现sentinel节点集合真正的高可用, 请勿将Sentinel节点部署在同一台物理机器上。
部署至少三个而且奇数个的sentinel节点
3个以上是通过增加Sentinel节点的个数提高对于故障判定的准确性, 因为领导者选举需要至少一半加1个节点, 奇数个节点可以在满足该条件的基础上节省一个节点。
只有一套sentinel,还是每个主节点配置一套sentinel
sentinel节点集合可以只监控一个主节点,也可以监控多个主节点。
- 一套sentinel:只需要维护固定个数的sentinel节点,集中对多个redis数据节点进行管理即可
- 多套sentinel:每个redis主节点都有自己的sentinel节点集合
如果sentinel节点集合监控的是同一个业务的多个主节点集合,那么【一套sentinel】,否则【方案二】