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

  前文我们了解了redis的常用数据类型相关命令的使用和说明,回顾请参考https://www.jb51.net/article/120364.htm 今天我们来聊一下redis的高可用组件sentinel;首先来回顾下redis的主从同步,主从同步最主要的作用是让master的数据在其他服务器上实时存在副本,起到了备份的效果;对于redis的读写来说,主从架构能够让读的请求分散到多个从服务器上,从而降低了单台redis读请求的io压力,同时也提高了redis读请求的并发能力;通常为了数据的一致性,从服务器一旦成为某一台redis的slave,那么从服务器上之前有的数据会被清空,然后把master发送过来的数据应用到内存,从而实现和master数据一致;除此之外slave通常会是只读属性,也就说slave端只能执行读操作,写操作会被拒绝,所以写请求始终是由master来完成;

那么问题来了,对于这种主从复制架构的环境中,如果master宕机了,master宕机意味着整个系统将不能够写数据到redis,很显然这种情况我们应该及时解决;怎么解决呢?有没有这样的一组件帮我们对master做实时的监控,一旦发现master宕机就提升一个slave当选新的master,如果原master还有其他slave,将其他slave都从属于新的master;除此之外它还应该让系统在发生切换master时触发报警通知,让管理员尽快把坏掉的master修复上线;对,sentinel就有我们上述的这些功能,它能够监控主从同步集群中的master节点,在master发生宕机后能够自动故障转移,将提升一台slave作为新的master,然后通知管理员;

  Sentinel是一个分布式系统,我们可以在一个架构中运行多个sentinel,这些sentinel进程使用流言协议(gossipprotocols)来接收关于 Master是否下线的信息,并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个 Slave 作为新的 Master。每个sentinel进程会向其他sentinel进程、master、slave定时发送消息,以确保对方是否”活”着,如果发现对方在指定配置时间(可配置的)内未得到回应,则暂时认为对方已掉线,也就是所谓的”主观认为宕机” ,英文名称:Subjective Down,简称 SDOWN。有主观宕机,肯定就有客观宕机。

当多个sentinel进程中多数的sentinel进程在对 Master 做出 SDOWN 的判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后,得出的 Master Server 下线判断,这种方式就是“客观宕机”,英文名称是:Objectively Down, 简称 ODOWN。通过一定的 vote 算法,从剩下的 slave 从服务器节点中,选一台提升为 Master 服务器节点,然后自动修改相关配置,并开启故障转移(failover)。

  配置使用sentinel

  环境说明

角色 ip地址 端口
master 192.168.0.41 6379
slave01 192.168.0.42 6379
slave02 192.168.0.43 6379
sentinel01 192.168.0.41 26379
sentinel02 192.168.0.42 26379
sentinel03 192.168.0.43 26379

  架构图

  提示:从上面的架构图可以知道,首先我们必须要有一个主从架构的集群,然后在部署sentinel 来对主从同步集群做监控;

  redis主从复制集群搭建

  1、在192.168.0.41/42/43上安装redis,可以使用yum安装,也可以使用编译安装,redis安装请参考https://www.jb51.net/article/79096.htm

  2、配置192.168.0.41/42/43上的redis监听在非本机127.0.0.1上并配置42/43上的redis从属于192.168.0.41

  master

  slave01

  slave02

  提示:redis支持在线修改配置,保存配置到配置文件;SLAVEOF 指令用于指定redismaster的ip地址和端口,表示把该redis配置成对应master的slave角色;CONFIG REWRITE是把我们的配置保存到配置文件;

  在master上查看是否有两个从节点连接到master

  验证:在master上写数据,看看是否能够及时同步到两个slave上?

  提示:可以看到在主库上写数据,从库上能够及时的同步主库上的数据;到此redis的主从集群就搭建完毕了;

  配置sentinel,让其监控master

  提示:三个sentinel的配置都是一样的,这里需要明确指定监控主从同步集群的master的ip地址和端口,以及有效法定票数,有效法定票数指的是至少有多少个sentinel主观认为master down了,然后才触发选举新master操作;通常在这种流言协议中,一般都是大于集群半数,如果是3台sentinel,至少要2台主观认为master宕机,才开始触发选举新master;如果是5台,那至少要3台;如果master配置的有认证密码,我们还需要在sentinel中指定认证密码;

  sentinel配置文件说明

  bind:该指令和redis配置文件中的bind是同样的用法,用于指定sentinel的监听地址;默认不指定,监听本机所有可用地址;

  protected-mode:指定是否开启保护模式;

  port:用于指定sentinel的监听端口;默认是26379

  daemonize:用于指定sentinel是否运行为守护进程,yes表示运行为后台守护进程;no表示不运行为守护进程,直接在前台运行;

  pidfile:指定pid文件路径;

  logfile:指定日志文件路径;

  dir:指定sentinel的工作路径;

  sentinel monitor <master-name> <ip> <redis-port> <quorum>:用于指定监控master节点的ip地址和端口以及有效法定票数;其中<master-name>是给监控的master一个名称,可以随便写,起标识的作用;<quorum>表示sentinel集群的quorum机制,即至少有quorum个sentinel节点同时判定主节点故障时,才认为其真的故障;

  sentinel auth-pass <master-name> <password>:指定master认证密码;通常都需要设置密码,并且master的密码和slave的密码应该是一样;

  sentinel down-after-milliseconds <master-name> <milliseconds>:配置监控到指定的集群的主节点异常状态持续多久方才将标记为“故障”;

  sentinel parallel-syncs <master-name> <numslaves>:指在failover过程中,能够被sentinel并行配置的从节点的数量;

  sentinel failover-timeout <master-name> <milliseconds>:sentinel必须在此指定的时长内完成故障转移操作,否则,将视为故障转移操作失败;

  sentinel notification-script <master-name> <script-path>:通知脚本,此脚本被自动传递多个参数;

  了解了sentinel的配置文件,接下我们把3台sentinel都启动起来

  master

  slave01

  slave02

  提示:从上面的信息可以看到3个sentinel都监控master的ip地址和端口,其实他们3个的配置文件都是一样的;

  查看sentinel日志

  提示:从上面的日志信息可以了解到sentinel监控的master是192.168.0.41:6379;并且有两个slave分别是192.168.0.42:6379和192.168.0.43:6379;

  查看sentinel状态

  提示:它提示我们开启了保护模式;

  关闭保护模式

  重启sentinel,再次查看sentinel状态

[root@master ~]# systemctl restart redis-sentinel.service
[root@master ~]# ss -tnl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 511 *:26379 *:*
LISTEN 0 511 *:6379 *:*
LISTEN 0 128 *:22 *:*
LISTEN 0 100 127.0.0.1:25 *:*
LISTEN 0 511 :::26379 :::*
LISTEN 0 128 :::22 :::*
LISTEN 0 100 ::1:25 :::*
[root@master ~]# redis-cli -h 192.168.0.41 -p 26379
192.168.0.41:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.0.41:6379,slaves=2,sentinels=3
192.168.0.41:26379> info clients
# Clients
connected_clients:3
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
192.168.0.41:26379> CLIENT LIST
id=2 addr=192.168.0.42:59048 fd=14 name=sentinel-f60b324b-cmd age=38 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
id=3 addr=192.168.0.43:37480 fd=15 name=sentinel-eada229c-cmd age=38 idle=1 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=publish
id=4 addr=192.168.0.41:36706 fd=16 name= age=32 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
192.168.0.41:26379>

  提示:从上面的状态信息可以看到当前sentinel监控的master是出于正常ok状态,有两个slave和3个sentinel;对于192.168.0.41:26379目前有3个客户端连接,二个是sentinel,一个本机;到此3台sentinel搭建启动完成;

  验证:把master宕机,看看sentinel是否将在两个从节点选举一个为新master?是否将另外一个slave重新指向新master?

  在slave01上查看主从同步信息

  提示:第一次查看只是告诉我们master宕机了,第二次查看就告诉我们当前节点为master,并且拥有一个slave节点,这说明已经完成了故障转移,slave01已经被提升为新的master了;

  在192.168.0.43上查看主从信息,看看是否指向新的master?

  提示:在slave02上看主从同步信息,可以看到slave02已经从属新master了;

  查看故障转移时 sentinel日志

  提示:从上面的日志信息可以了解到,在从sdown到odown后,就会触发vote算法开始选举leader;然后将原master降级为slave,然后将选举出来的leader原salve属性去除(slaveof no one);然后提升新master,然后将剩下的slave重新配置新master为主;最后是切换master,开始新的监控;

  查看故障 转移后的 redis 配置文件

  提示:故障转移后 redis.conf 中的 slaveof 行的 master IP 会被修改,sentinel.conf 中的 sentinel monitor IP 会被修改。同时在sentinel配置文件的末尾还会有添加known-slave和known-sentinel等信息;

  修复旧master 让其重新上线

  提示:把原master启动后,它自动就成为了新主的slave;这主要是因为sentinel在故障转移时把其配置文件中的slaveof 修改成新的master地址了;

  在新master上查看主从同步信息

  提示:在没有恢复原master时,在新master上查看主从同步信息,只能看到一个salve,启动原master后,在看就有两个slave是在线;

总结

到此这篇关于Redis服务之高可用组件sentinel的文章就介绍到这了,更多相关Redis服务之高可用组件sentinel内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 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<

  • SpringCloud实现Redis在各个微服务的Session共享问题

    在微服务中,需要我们在各个微服务中共享Session,使用Redis来共享Session是一个很好的解决方法,Redis是运行在内存中,查取速度很快. 1.pom文件中添加依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-redis</artifactId> </dependency> <depe

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

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

  • 解决redis服务启动失败的问题

    最近学redis,就遇到了各种坑,在这里分享一下 我是将redis做成后台 安装,配置环境变量统统省略掉了. 做成后台服务呢,首先,cd到redis的安装目录下,再cd到util,接着执行 ./install_server.sh 然后修改服务名称,将原来的redis_6379更名为redisd,这样下次启动比较方便,命令如下: cd /etc/init.d/ mv redis_6379 redisd 然后,就可以启动redis服务了 service redisd start 启动之后,就可以进入

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

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

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

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

  • nginx+keepalived 高可用主从配置详解

    本文介绍了nginx+keepalived 高可用主从配置详解,分享给大家,具体如下: 一.系统环境及软件版本 CentOS 6.6 x64 keepalived-1.2.18.tar.gz nginx-1.6.2.tar.gz 主服务器:192.168.38.64 从服务器:192.168.38.66 VIP :192.168.38.100 二.nginx安装 (主从安装一致) 1.安装依赖环境 复制代码 代码如下: yum install gcc gcc-c++ make automake

  • redis客户端实现高可用读写分离的方式详解

    背景 (1) redis单机的读写性能轻松上大几万,不过线上环境不会只部署光秃秃的一个节点,还是会配合 sentinel 再部署一个 slave作为高可用节点的: 但是standby的slave节点是不对外提供服务端的,一定程度上造成了浪费资源 (2) 当业务不断发展,原来单节点缓存的数据(如,商品信息缓存.配置信息等)的查询qps不断升高(写qps增长不多),突破十几万.几十万的的时候,此时一个节点就扛不住了,我们就需要增加几个redis slaves节点来分担这些查询的压力 也就是读写分离

  • redis三种高可用方式部署的实现

    前言 一.主从复制 概念 和mysql的主从复制一样 都是将服务器的数据复制到另一个数据库中 发送的称为master 接受的叫slave 数据为单向传输 只可以主到从 每台Redis服务器都是主节点:且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点. 作用 数据冗余 实现了数据的热备份,是持久化之外的一种数据冗余方式 故障切换 当主节点宕机或者出现错误时 由从服务器来提供服务 实现故障切换 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供

  • 浅谈Redis哨兵模式高可用解决方案

    目录 一.序言 1.目标与收获 2.端口规划 二.单机模拟 (一)服务规划 1.Redis实例 2.哨兵服务 (二)服务配置 1.Redis实例 2.哨兵服务 (三)服务管理 1.Redis实例 2.哨兵服务 三.客户端整合 (一)基础整合 1.全局配置文件 2.集成配置 (二)读写分离 一.序言 Redis高可用有两种模式:哨兵模式和集群模式,本文基于哨兵模式搭建一主两从三哨兵Redis高可用服务. 1.目标与收获 一主两从三哨兵Redis服务,基本能够满足中小型项目的高可用要求,使用Supe

  • Kotlin Service服务组件开发详解

    目录 服务简介 服务的创建 服务的启动方式 Service的生命周期 Activity和Service进行通信 实现前台Service 服务简介 服务是Android中的四大组件之一,它能够长期在后台运行且不提供用户界面.即使用户切到另一应用程序,服务仍可以在后台运行. 服务的创建 (1)创建Service子类 class MyService : Service() { override fun onBind(intent: Intent): IBinder { TODO("Return the

  • 对jquery的ajax进行二次封装以及ajax缓存代理组件:AjaxCache详解

    虽然jquery的较新的api已经很好用了, 但是在实际工作还是有做二次封装的必要,好处有:1,二次封装后的API更加简洁,更符合个人的使用习惯:2,可以对ajax操作做一些统一处理,比如追加随机数或其它参数.同时在工作中,我们还会发现,有一些ajax请求的数据,对实时性要求不高,即使我们把第一次请求到的这些数据缓存起来,然后当相同请求再次发起时直接拿之前缓存的数据返回也不会对相关功能有影响,通过这种手工的缓存控制,减少了ajax请求,多多少少也能帮助我们提高网页的性能.本文介绍我自己关于这两方

  • Redis快速实现分布式session的方法详解

    目录 前言 Spring Security Apache Shiro Session作用 spring-session 支持功能 分布式seesion实战 步骤1:依赖包 步骤2:配置文件 步骤3:实现逻辑 步骤4:编写session拦截器 步骤5:把拦截器注入到拦截器链中 步骤6:测试 前言 我们在开发一个项目时通常需要登录认证,常用的登录认证技术实现框架有Spring Security和shiro Spring Security Spring Security是一个功能强大且高度可定制的身份

  • 微服务架构之服务注册与发现实践示例详解

    目录 1 服务注册中心 4种注册中心技术对比 2 Spring Cloud 框架下实现 2.1 Spring Cloud Eureka 2.1.1 创建注册中心 2.1.2 创建客户端 2.2 Spring Cloud Consul 2.2.1 Consul 的优势 2.2.2 Consul的特性 2.2.3 安装Consul注册中心 2.2.4 创建服务提供者 3 总结 微服务系列前篇 详解微服务架构及其演进史 微服务全景架构全面瓦解 微服务架构拆分策略详解 微服务架构之服务注册与发现功能详解

  • Vite多环境配置项目高定制化能力详解

    目录 业务背景 多环境场景的业务形态 Vite多环境方案实现 多模式文件配置 自定义环境变量 Vite默认环境变量 通过插件透传环境变量 客户端环境差异定制 效果图 解决的业务场景思考 业务背景 近些年来,随着前端工程架构发展,使得前端项目中也能拥有如后端工程的模块能力.正所谓 “能力(越)越大(来),责任(越)越大(卷)”,现在的前端工程不仅仅要满足业务需求,还伴随更多复杂的环境适配问题,例如: api请求的域名会根据不同环境而不同: 线上环境和测试环境在打包策略有所不同「如线上要隔离sour

随机推荐