spring集成redis——主从配置以及哨兵监控

2024-06-22 11:32
文章标签 java 配置 redis spring 哨兵 集成 监控 主从

本文主要是介绍spring集成redis——主从配置以及哨兵监控，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

Redis主从模式配置：

Redis的主从模式配置是非常简单的，首先我们需要有2个可运行的redis环境：

master node : 192.168.56.101 8887

slave node:     192.168.56.102 7777

 

我们只要在slave 节点的配置文件中，找到 slaveof开头

然后修改为：（master的ip与端口）

slaveof 192.168.56.101  8777

这样就可以了，下面我们来验证一下，首先启用master和slave的redis服务，然后登录redis-cli，输入info

然后看下192.168.56.101：8887的信息，红色的地方，表示当前节点为master节点，有几个从节点和从节点的信息

192.168.56.101:8887> info
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.56.102,port=7777,state=online,offset=568,lag=1
master_repl_offset:568
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:567

在看192.168.56.102：7777的信息

192.168.56.102:7777> info
# Replication
role:slave
master_host:192.168.56.101
master_port:8887
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:918
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

在master，创建一个key-value：

192.168.56.101:8887> set aa aa
OK

在slave节点

192.168.56.102:7777> get aa
"aa"

因为默认的设置从节点是不能写只能读的，所以如果要在从节点写东西是报错的，如下：

192.168.56.102:7777> set aa 2a
(error) READONLY You can't write against a read only slave.

这样一来主从模式就好了，如果要有多个从节点，只要改变他们的slaveof的配置就行了。

当然如果只这样配置，在生产上面是没有多大用处的，因为如果无论master节点还是slave节点挂了，我们都要手动启动来让他继续恢复工作，那么能不能让他自动恢复呢？比如master挂掉了，在slave节点中选一个节点自动更换成master。根据这个需求，redis在2.4之后出现了sentinel，其目的就是监控主从节点的健壮性，然后自动选举master节点下面就来看看如何配置sentinel。

Redis 的 Sentinel配置

一、Sentinel介绍

Sentinel是Redis的高可用性（HA）解决方案，由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进行下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。Redis提供的sentinel（哨兵）机制，通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决

  • 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
  • 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
  • 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器

 

二、Sentinel的主从原理

 

  

三、Redis Sentinel配置

这里采用了一个master 一个slave 一个sentinel

master 的redis.conf配置，找到下面的并修改：

port 8887
bind 192.168.56.101

slave 的redis.conf配置，找到下面的并修改，如果master节点设置了密码，下面红色部分要加上

port 7777
bind 192.168.56.102
slaveof 192.168.56.101 8887
masterauth master的密码

sentinel的sentinel.conf 配置

port 9999
protected-mode yes
bind 192.168.56.101
dir /tmp
sentinel monitor mymaster 192.168.56.101 8887 1
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 15000

tips:

如果停掉master 后，sentinel 显示足够数量的 sdown 后，没有出现odown或try-failover，则检查密码等配置是否正确

如果停掉master后，试图切换的时候出现 failover-abort-not-elected 

1）如果redis实例没有配置
protected-mode yes
bind 192.168.56.101
则在sentinel 配置文件加上
protected-mode no 
2）如果redis实例有配置
protected-mode yes
bind 192.168.56.101
则在sentinel 配置文件加上
protected-mode yes
bind 192.168.56.101

上面的配置都弄好之后，分别启动master、slave、sentinel(前面2个是redis-service 启动，后面是redis-sentinel)服务，然后我们可以redis-cli查看对于的info信息（跟上面主从操作是一样的）

master节点

[root@localhost 8887]# ./redis-cli -h 192.168.56.101 -p 8887
192.168.56.101:8887> info
……
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.56.102,port=7777,state=online,offset=6503,lag=1
master_repl_offset:6647
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:6646
……

slave节点

[root@localhost 7777]# ./redis-cli -h 192.168.56.102 -p 7777
192.168.56.102:7777> info
……
# Replication
role:slave
master_host:192.168.56.101
master_port:8887
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:918
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
……

sentinel节点信息

[root@localhost 8887]# ./redis-cli -h 192.168.56.101 -p 9999
192.168.56.101:9999> info 
……
# 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.56.101:8887,slaves=1,sentinels=1
……

下面我们把master节点给干掉，

192.168.56.101:8887> SHUTDOWN
not connected>

这个时候，在sentinel界面会输出下面的信息：

4338:X 05 Jun 14:57:27.313 # +sdown master mymaster 192.168.56.101 8887
4338:X 05 Jun 14:57:27.313 # +odown master mymaster 192.168.56.101 8887 #quorum 1/1
4338:X 05 Jun 14:57:27.313 # +new-epoch 17
4338:X 05 Jun 14:57:27.313 # +try-failover master mymaster 192.168.56.101 8887
4338:X 05 Jun 14:57:27.317 # +vote-for-leader 9354edabc95f19b3d99991f0877d0e66ada04e5b 17
4338:X 05 Jun 14:57:27.317 # +elected-leader master mymaster 192.168.56.101 8887
4338:X 05 Jun 14:57:27.317 # +failover-state-select-slave master mymaster 192.168.56.101 8887
4338:X 05 Jun 14:57:27.384 # +selected-slave slave 192.168.56.102:7777 192.168.56.102 7777 @ mymaster 192.168.56.101 8887
4338:X 05 Jun 14:57:27.384 * +failover-state-send-slaveof-noone slave 192.168.56.102:7777 192.168.56.102 7777 @ mymaster 192.168.56.101 8887
4338:X 05 Jun 14:57:27.450 * +failover-state-wait-promotion slave 192.168.56.102:7777 192.168.56.102 7777 @ mymaster 192.168.56.101 8887
4338:X 05 Jun 14:57:28.255 # +promoted-slave slave 192.168.56.102:7777 192.168.56.102 7777 @ mymaster 192.168.56.101 8887
4338:X 05 Jun 14:57:28.255 # +failover-state-reconf-slaves master mymaster 192.168.56.101 8887
4338:X 05 Jun 14:57:28.317 # +failover-end master mymaster 192.168.56.101 8887
4338:X 05 Jun 14:57:28.317 # +switch-master mymaster 192.168.56.101 8887 192.168.56.102 7777
4338:X 05 Jun 14:57:28.318 * +slave slave 192.168.56.101:8887 192.168.56.101 8887 @ mymaster 192.168.56.102 7777

现在我们在查看以前的slave节点：

192.168.56.102:7777> info
……
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
……

这个时候以前的slave变成了master，所以现在没有从节点了，所以 connected_slaves:0 ，下面我们把干掉的192.168.56.101 8887服务给启用，然后在查看现在的master，

192.168.56.102:7777> info
……
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.56.101,port=8887,state=online,offset=1334,lag=0
master_repl_offset:1334
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:1333
……

这个时候可以看到，多出了一个slave，即以前的master变成了从节点，我们再看以前的master节点信息：

192.168.56.101:8887> info
……
# Replication
role:slave
master_host:192.168.56.102
master_port:7777
master_link_status:up
master_last_io_seconds_ago:2
master_sync_in_progress:0
slave_repl_offset:7364
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
……

上面就是sentinel自动的对redis的主从切换的配置，以及信息的变化，下面来看在Spring中如何配置。

四、Spring中 Sentinel配置

pom.xml文件中添加依赖包

<!--redis 支持java的语言 --><dependency><groupId>redis.clients</groupId><artifactId>jedis</artifactId><version>2.9.0</version></dependency><!-- spring data redis --><dependency><groupId>org.springframework.data</groupId><artifactId>spring-data-redis</artifactId><version>1.8.1.RELEASE</version></dependency>

spring-redis.xml的配置：

<!--redis哨兵 --><bean id="redisSentinelConfiguration"class="org.springframework.data.redis.connection.RedisSentinelConfiguration"><property name="master"><bean class="org.springframework.data.redis.connection.RedisNode"><property name="name" value="mymaster"/></bean></property><property name="sentinels"><set><bean class="org.springframework.data.redis.connection.RedisNode"><constructor-arg name="host" value="192.168.56.101"/><constructor-arg name="port" value="9999"/></bean>  </set></property></bean><bean id="jedisConnFactory"class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory"><!--<property name="hostName" value="${redis.host}"/>--><!--<property name="port" value="${redis.port}"/>--><!--<property name="password" value="${redis.password}"/>--><!--<property name="usePool" value="false"/>--><!--<property name="poolConfig" ref="poolConfig"/>--><constructor-arg name="sentinelConfig" ref="redisSentinelConfiguration"/></bean><bean id="stringRedisTemplate" class="org.springframework.data.redis.core.StringRedisTemplate"><property name="connectionFactory" ref="jedisConnFactory"/></bean>

tips:

第25行如果我们不配poolConfig的话，也不要把第24行的usePool改成false，如果把usePool改成false，那么上面的哨兵配置好像就无效了。

 

Sentinel模式下的几个事件

  • +reset-master ：主服务器已被重置。
  • +slave ：一个新的从服务器已经被 Sentinel 识别并关联。
  • +failover-state-reconf-slaves ：故障转移状态切换到了 reconf-slaves 状态。
  • +failover-detected ：另一个 Sentinel 开始了一次故障转移操作，或者一个从服务器转换成了主服务器。
  • +slave-reconf-sent ：领头（leader）的 Sentinel 向实例发送了 [SLAVEOF](/commands/slaveof.html) 命令，为实例设置新的主服务器。
  • +slave-reconf-inprog ：实例正在将自己设置为指定主服务器的从服务器，但相应的同步过程仍未完成。
  • +slave-reconf-done ：从服务器已经成功完成对新主服务器的同步。
  • -dup-sentinel ：对给定主服务器进行监视的一个或多个 Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情况。
  • +sentinel ：一个监视给定主服务器的新 Sentinel 已经被识别并添加。
  • +sdown ：给定的实例现在处于主观下线状态。
  • -sdown ：给定的实例已经不再处于主观下线状态。
  • +odown ：给定的实例现在处于客观下线状态。
  • -odown ：给定的实例已经不再处于客观下线状态。
  • +new-epoch ：当前的纪元（epoch）已经被更新。
  • +try-failover ：一个新的故障迁移操作正在执行中，等待被大多数 Sentinel 选中（waiting to be elected by the majority）。
  • +elected-leader ：赢得指定纪元的选举，可以进行故障迁移操作了。
  • +failover-state-select-slave ：故障转移操作现在处于 select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。
  • no-good-slave ：Sentinel 操作未能找到适合进行升级的从服务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接放弃执行故障转移操作。
  • selected-slave ：Sentinel 顺利找到适合进行升级的从服务器。
  • failover-state-send-slaveof-noone ：Sentinel 正在将指定的从服务器升级为主服务器，等待升级功能完成。
  • failover-end-for-timeout ：故障转移因为超时而中止，不过最终所有从服务器都会开始复制新的主服务器（slaves will eventually be configured to replicate with the new master anyway）。
  • failover-end ：故障转移操作顺利完成。所有从服务器都开始复制新的主服务器了。
  • +switch-master ：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。
  • +tilt ：进入 tilt 模式。
  • -tilt ：退出 tilt 模式。

 

这篇关于spring集成redis——主从配置以及哨兵监控的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1084164。

相关文章

Redis客户端连接机制的实现方案

Redis客户端连接机制的实现方案

《Redis客户端连接机制的实现方案》本文主要介绍了Redis客户端连接机制的实现方案,包括事件驱动模型、非阻塞I/O处理、连接池应用及配置优化,具有一定的参考价值,感兴趣的可以了解一下... 目录1. Redis连接模型概述2. 连接建立过程详解2.1 连php接初始化流程2.2 关键配置参数3. 最大连
阅读更多...
SpringBoot多环境配置数据读取方式

SpringBoot多环境配置数据读取方式

《SpringBoot多环境配置数据读取方式》SpringBoot通过环境隔离机制,支持properties/yaml/yml多格式配置,结合@Value、Environment和@Configura... 目录一、多环境配置的核心思路二、3种配置文件格式详解2.1 properties格式（传统格式）1.
阅读更多...
Apache Ignite 与 Spring Boot 集成详细指南

Apache Ignite 与 Spring Boot 集成详细指南

《ApacheIgnite与SpringBoot集成详细指南》ApacheIgnite官方指南详解如何通过SpringBootStarter扩展实现自动配置,支持厚/轻客户端模式,简化Ign... 目录 一、背景：为什么需要这个集成？ 二、两种集成方式（对应两种客户端模型） 三、方式一：自动配置 Thick
阅读更多...
Spring WebClient从入门到精通

Spring WebClient从入门到精通

《SpringWebClient从入门到精通》本文详解SpringWebClient非阻塞响应式特性及优势,涵盖核心API、实战应用与性能优化,对比RestTemplate,为微服务通信提供高效解决... 目录一、WebClient 概述1.1 为什么选择 WebClient？1.2 WebClient 与
阅读更多...
Java.lang.InterruptedException被中止异常的原因及解决方案

Java.lang.InterruptedException被中止异常的原因及解决方案

《Java.lang.InterruptedException被中止异常的原因及解决方案》Java.lang.InterruptedException是线程被中断时抛出的异常,用于协作停止执行,常见于... 目录报错问题报错原因解决方法Java.lang.InterruptedException 是 Jav
阅读更多...
深入浅出SpringBoot WebSocket构建实时应用全面指南

深入浅出SpringBoot WebSocket构建实时应用全面指南

《深入浅出SpringBootWebSocket构建实时应用全面指南》WebSocket是一种在单个TCP连接上进行全双工通信的协议,这篇文章主要为大家详细介绍了SpringBoot如何集成WebS... 目录前言为什么需要 WebSocketWebSocket 是什么Spring Boot 如何简化 We
阅读更多...
java中pdf模版填充表单踩坑实战记录(itextPdf、openPdf、pdfbox)

java中pdf模版填充表单踩坑实战记录(itextPdf、openPdf、pdfbox)

《java中pdf模版填充表单踩坑实战记录(itextPdf、openPdf、pdfbox)》：本文主要介绍java中pdf模版填充表单踩坑的相关资料,OpenPDF、iText、PDFBox是三... 目录准备Pdf模版方法1：itextpdf7填充表单（1）加入依赖（2）代码（3）遇到的问题方法2：pd
阅读更多...
Java Stream流之GroupBy的用法及应用场景

Java Stream流之GroupBy的用法及应用场景

《JavaStream流之GroupBy的用法及应用场景》本教程将详细介绍如何在Java中使用Stream流的groupby方法,包括基本用法和一些常见的实际应用场景,感兴趣的朋友一起看看吧... 目录Java Stream流之GroupBy的用法1. 前言2. 基础概念什么是 GroupBy？Stream
阅读更多...
Debian系和Redhat系防火墙配置方式

Debian系和Redhat系防火墙配置方式

《Debian系和Redhat系防火墙配置方式》文章对比了Debian系UFW和Redhat系Firewalld防火墙的安装、启用禁用、端口管理、规则查看及注意事项,强调SSH端口需开放、规则持久化,... 目录Debian系UFW防火墙1. 安装2. 启用与禁用3. 基本命令4. 注意事项5. 示例配置R
阅读更多...
SpringBoot监控API请求耗时的6中解决解决方案

SpringBoot监控API请求耗时的6中解决解决方案

《SpringBoot监控API请求耗时的6中解决解决方案》本文介绍SpringBoot中记录API请求耗时的6种方案,包括手动埋点、AOP切面、拦截器、Filter、事件监听、Micrometer+... 目录1. 简介2.实战案例2.1 手动记录2.2 自定义AOP记录2.3 拦截器技术2.4 使用Fi
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2