Redis Sentinel的基本搭建

Redis Sentinel的概念

我们知道Redis主从模式下,一旦主节点由于故障不能提供服务,需要人工将从节点晋升为主节点,同时还要通知应用方更新主节点的地址。然后在很多应用场景下这种故障处理的方式是无法接受的,应用程序需要实时感知当前的可用节点。为了解决这个问题,Redis Sentinel应运而生,也称之为"哨兵"。

介绍sentinel之前,先来了解几个redis的概念,

主节点master:Redis进程,主服务

从节点slave:redis进程,从服务

Redis数据节点:主节点和从节点

Sentinel节点:监控Redis数据节点,独立的sentinel进程

Sentinel节点集合:若干Sentinel节点的抽象组合,若干sentinel节点进程

Redis Sentinel:Redis高可用实现方案,sentinel节点集合和redis数据节点进程

01 主从复制问题

前面的文章中我们讲述了主从复制,可以将从节点作为主节点的灾备节点,今天我们来看主从复制带来的问题:

1、一旦主节点发生故障,从节点晋升为主节点的过程和应用调整新主节点的过程,都需要人为干预

2、主节点的写能力容易受到单机的限制

3、主节点的存储能力容易受到单机的限制

一种常见的方法是使用脚本来触发主从节点的角色切换,例如在一个一主两从的结构中,假设主节点master,从节点slave1,slave2,我们来看故障发生时架构的状态:

1、主节点master故障,客户端连接失败,两个从节点复制失败

2、选择一个主节点slave1,对其执行slave of no one命令使其成为主节点master2

3、更新应用程序连接的节点为slave1的IP地址

4、slave2以slave1为新的主节点,复制slave1上的命令

5、待原来的master恢复之后,让它成为slave1的从节点。

上述过程可以做成自动化的过程,但是需要考虑三点:a、要确保判断节点不可达的机制健全,否则容易出现误判断情况

b、如果有多个从节点,如果保证只有一个从节点被晋升为主节点是个关键的问题

c、通知客户端新的主节点的机制是否足够健壮

02 Redis Sentinel的高可用机制

Sentinel能够自动完成故障发现和故障转移,并及时通知应用方。这是它的核心价值所在。

Redis Sentinel是一个分布式架构,其中包含若干个Sentinel和若干个Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线表示。如果被标识的是主节点,它还会和其他的sentinel进行协商,当大多数sentinel节点都认为主节点不可达时,他们会选举出来一个sentinel节点来实现故障自动转移,同时会将这个变化通知给Redis应用方,整个过程是自动的,不需要人工介入。

Redis Sentinel与Redis主从复制模式只是多了若干个sentinel节点,并没有对redis节点做特殊处理,这是很多redis开发和运维人员容易混淆的地方。

二者架构图如下:

在整个主服务故障到重新选择主服务的过程中,sentinel主要干如下几件事情:

1、监控,sentinel节点会定期检测redis数据节点,其余sentinel节点是否可达

2、通知,sentinel节点会将故障转移的结果通知给应用方。

3、主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系

4、配置提供者:在redis sentinel结构中,客户端在初始化的时候连接的是sentinel节点集合,从中获取主节点信息

上面的架构图中不难发现sentinel也是多个的,这样的好处有两个:

1、可以保证sentinel的健壮性,一个sentinel挂了,不影响整个集群的功能。

2、对于节点的故障判断是多个sentinel同时判断出来的,有效的防止了误判

sentinel节点本身其实就是独立的redis节点,只不过它们不存处数据,只支持部分命令。

接下来,我们来看sentinel的部署和配置文件内容。

03 sentinel部署

sentinel部署之前,需要先有master和两个slave的一主两从架构:

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=169,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=169,lag=1
master_repl_offset:183
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:182

sentinel的部署配置文件:

[root@VM_48_10_centos redis]# cat redis-sentinel-26379.conf 
port 26379
daemonize yes
logfile "26379.log"
dir "/usr/local/redis-3.0.7"
sentinel monitor mymaster 127.0.0.1 6379 2

其中,sentinel monitor mymaster代表sentinel要监控主节点6379,2代表判断主节点失败至少需要2个sentinel节点同意。

其余两个sentinel的配置文件和这个大同小异,只需要修改对应端口和日志文件即可。sentinel启动命令如下:

[root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26379.conf &
[1] 7311
[root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26380.conf &
[1] 7366
[root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26381.conf &
[2] 7380
[root@VM_48_10_centos redis]# 
[root@VM_48_10_centos redis]# ps -ef|grep sentinel
root      7312     1  0 22:51 ?        00:00:00 redis-sentinel *:26379 [sentinel]
root      7367     1  0 22:52 ?        00:00:00 redis-sentinel *:26380 [sentinel]
root      7381     1  0 22:52 ?        00:00:00 redis-sentinel *:26381 [sentinel]
root      7405  5850  0 22:52 pts/7    00:00:00 grep --color=auto sentinel

此时,重新查看26379这个sentinel的配置文件,会发现里面多了一些内容:

[root@VM_48_10_centos redis]# cat redis-sentinel-26379.conf 
port 26379
daemonize yes
logfile "26379.log"
dir "/usr/local/redis-3.0.7"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
sentinel known-slave mymaster 127.0.0.1 6380
# Generated by CONFIG REWRITE
sentinel known-slave mymaster 127.0.0.1 6381
sentinel known-sentinel mymaster 127.0.0.1 26381 0a2c77616ef88282fa12ef7c8aca142a2473cd5a
sentinel known-sentinel mymaster 127.0.0.1 26380 3ad6460bf5f4b01f277fdce3aa423d596993eec5
sentinel current-epoch 0

可以发现,sentinel之间已经进行了交互,并写入了配置文件中一些已经获取到的内容。

使用命令info sentinel查看当前sentinel集群的信息:

[root@VM_48_10_centos redis]# redis-cli -h 127.0.0.1 -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=127.0.0.1:6379,slaves=2,sentinels=3

以上就是Redis Sentinel的使用的详细内容,更多关于Redis Sentinel的资料请关注我们其它相关文章!

(0)

相关推荐

  • Redis服务之高可用组件sentinel详解

    前文我们了解了redis的常用数据类型相关命令的使用和说明,回顾请参考https://www.jb51.net/article/120364.htm 今天我们来聊一下redis的高可用组件sentinel:首先来回顾下redis的主从同步,主从同步最主要的作用是让master的数据在其他服务器上实时存在副本,起到了备份的效果:对于redis的读写来说,主从架构能够让读的请求分散到多个从服务器上,从而降低了单台redis读请求的io压力,同时也提高了redis读请求的并发能力:通常为了数据的一致性

  • java客户端Jedis操作Redis Sentinel 连接池的实现方法

    pom.xml配置 <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-redis</artifactId> <version>1.0.2.RELEASE</version> </dependency> <dependency> <groupId>redis.clients<

  • Linux redis-Sentinel配置详解

    下载 下载地址:https://redis.io/download 在/usr/local/src目录下执行下载. wget http://download.redis.io/releases/redis-3.2.8.tar.gz 安装 解压到/usr/local/src目录,放源码包. tar xzf redis-3.2.8.tar.gz 创建目录/usr/local/redis: make dir /usr/local/redis 进入源码目录: cd /usr/local/src/redi

  • Redis Sentinel的使用方法

    1.sentinel monitor 用法: sentinel monitor master-name  ip port quorum 其中,master-name是主节点的名称,ip,port不用解释,是主节点的地址信息. 最后的quorum是判断主节点最终不可达所需要的票数.这个值越大,判断越可信,这个值越小,判断越不可信,一般这个数字取的是sentinel节点数目的一半+1.同时,该值还与sentinel节点的领导者选举有关,至少要有max(quorum,num (sentinel)/2+

  • 详解SpringBoot Redis自适应配置(Cluster Standalone Sentinel)

    核心代码段 提供一个JedisConnectionFactory  根据配置来判断 单点 集群 还是哨兵 @Bean @ConditionalOnMissingBean public JedisConnectionFactory jedisConnectionFactory() { JedisConnectionFactory factory = null; String[] split = node.split(","); Set<HostAndPort> nodes =

  • Redis Sentinel服务配置流程(详解)

    1.Redis Sentinel服务配置 1.1简介 Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务: 监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常. 提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过API 向管理员或者其他应用程序发送通知. 自动故障迁移(Automatic failover): 当一个主服务器不

  • Redis Sentinel实现高可用配置的详细步骤

    一般情况下yum安装redis的启动目录在:/usr/sbin :配置目录在/etc/redis/在其目录下会有默认的redis.conf和redis-sentinel.conf redis高可用配置: 配置哨兵(redis-sentinel),我的所有配置文件都放在/etc/redis-cluster/目录下 1.创建redis-sentinel_26379.conf,主要内容如下: #基本配置 port 26379 daemonize yes logfile "/var/log/redis/

  • 玩转Redis搭建集群之Sentinel详解

    前言 Redis作为内存数据库,需要具备高可用的特点,不然如果服务器宕机,还在内存里的数据就会丢失.我们最常用的高可用方法就是搭建集群,master机器挂了,可以让slave机器顶上,继续提供服务.但是Redis集群是不会自动进行主从切换的,也就是说,如果主节点非常不争气的在凌晨3点挂了,那么运维同学就要马上起床,把从节点改成主节点,这样的操作是非常繁琐低效的.为此,Redis官方提供了一种解决方案:Redis Sentinel 简介 Redis Sentinel集群通常由3到5个节点组成,如果

  • Redis Sentinel实现哨兵模式搭建小结

    Redis哨兵模式,用现在流行的话可以说就是一个"哨兵机器人",给"哨兵机器人"进行相应的配置之后,这个"机器人"可以7*24小时工作,它能能够自动帮助你做一些事情,如监控,提醒,自动处理故障等. Redis-sentinel简介 Redis-sentinel是Redis的作者antirez,因为Redis集群的被各大公司使用,每个公司要写自己的集群管理工具,于是antirez花了几个星期写出了Redis-sentinel. Redis 的 Se

  • 基于docker搭建redis-sentinel集群的方法示例

    1.概述 Redis 集群可以在一组 redis 节点之间实现高可用性和 sharding.在集群中会有 1 个 master 和多个 slave 节点.当 master 节点失效时,应选举出一个 slave 节点作为新的 master.然而 Redis 本身(包括它的很多客户端)没有实现自动故障发现并进行主备切换的能力,需要外部的监控方案来实现自动故障恢复. Redis Sentinel 是官方推荐的高可用性解决方案.它是 Redis 集群的监控管理工具,可以提供节点监控.通知.自动故障恢复和

随机推荐