SpringBoot Redis入门（四）——Redis单机、哨兵、集群模式

  • 单机模式：单台缓存服务器，开发、测试环境下使用；
  • 哨兵模式：主-从模式，提高缓存服务器的高可用和安全性。所有缓存的数据在每个节点上都一致。每个节点添加监听器，不断监听节点可用状态，一旦主节点不能再提供服务。各监听器会立即在“从节点“中投票选择一台将之作为”主节点“器。从而使业务系统服务不会被中断。当然主节点具体出了什么问题，还得运维人员排查并及时修复并上线；
  • 集群模式：分布式+主从模式，具有高可用、安全性高、数据量大、并发量大等优势。一般需要6台服务器，3台主+3台从。一般在缓存数据量大或者并发访问量非常高以至于单台服务器已经无法承受这样的数据量或访问量时才考虑集群模式。集群模式中几台主服务器中的数据是不一致的，只有主和从中的数据是相同的。

在SpringBoot中使用哨兵模式和集群模式，也是不费吹灰之力。对于我们使用来说和前面单机模式没有任何区别。唯一需要做的就是告诉SbringBoot框架：这个项目我要使用哨兵模式，这个项目我要使用集群模式。如何告诉框架呢，当然是通过application.yml文件中的配置来说明：
pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"><parent><artifactId>lab-03-redis</artifactId><groupId>com.luo</groupId><version>1.0-SNAPSHOT</version></parent><modelVersion>4.0.0</modelVersion><artifactId>lab-03-redis-06-redis-cluster</artifactId><properties><maven.compiler.source>8</maven.compiler.source><maven.compiler.target>8</maven.compiler.target></properties><dependencies><!-- 实现对 Spring MVC 的自动化配置 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><!-- 实现对 Spring Data Redis 的自动化配置 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId></dependency><!-- pool 对象池 --><dependency><groupId>org.apache.commons</groupId><artifactId>commons-pool2</artifactId></dependency><!-- 阿里JSON解析器 --><dependency><groupId>com.alibaba.fastjson2</groupId><artifactId>fastjson2</artifactId><version>2.0.34</version></dependency><!-- 引入 Swagger 依赖 --><dependency><groupId>io.springfox</groupId><artifactId>springfox-swagger2</artifactId><version>2.9.2</version></dependency><!-- 引入 Swagger UI 依赖，以实现 API 接口的 UI 界面 --><dependency><groupId>io.springfox</groupId><artifactId>springfox-swagger-ui</artifactId><version>2.9.2</version></dependency><!-- 方便等会写单元测试 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency><dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.12</version><scope>test</scope></dependency></dependencies></project>

关于使用哨兵模式的Redis缓存配置：

spring:profiles:active: cluster
---
spring:profiles: standalone# 默认使用的是lettuce框架封装的redis操作# 默认连接redis的s顺序： 先 Sentinel哨兵模式 -> Cluster集群 -> 单机Redisredis:host: 127.0.0.1 # 连接redis的ipport: 6379database: 0 # 连接的是redis的几号数据库password: 123456  # 连接redis的密码lettuce:#      连接池pool:max-wait: 100ms  # 连接的最大等待时间max-active: 8  # 最大连接数max-idle: 4 # 最大空闲连接数min-idle: 0 # 最小空闲连接数---
spring:profiles: sentinelredis:host: 127.0.0.1 # 连接redis的ipport: 6379database: 0 # 连接的是redis的几号数据库password: 123456  # 连接redis的密码lettuce:#      连接池pool:max-wait: 100ms  # 连接的最大等待时间max-active: 8  # 最大连接数max-idle: 4 # 最大空闲连接数min-idle: 0 # 最小空闲连接数sentinel:master: mymaster  # 配置哨兵时候master的名字nodes:- 127.0.0.1:26379- 127.0.0.1:26380- 127.0.0.1:26381---
spring:profiles: clusterredis:host: 127.0.0.1 # 连接redis的ipport: 6379database: 0 # 连接的是redis的几号数据库password: 123456  # 连接redis的密码lettuce:#      连接池pool:max-wait: 100ms  # 连接的最大等待时间max-active: 8  # 最大连接数max-idle: 4 # 最大空闲连接数min-idle: 0 # 最小空闲连接数# 配置集群cluster:nodes:- 127.0.0.1:6379- 127.0.0.1:6380- 127.0.0.1:6381- 127.0.0.1:7379- 127.0.0.1:7380- 127.0.0.1:7381

哨兵模式的配置中，特别注意：*ndes配置的是哨兵的IP和端口，并非缓存服务器的；
集群模式的配置，都是缓存服务器的IP和端口。

接下来我们验证一下哨兵模式和集群模式在使用结果上的差异；

哨兵模式

如下图所示：三台缓存服务器，每台服务都有对应哨兵；
在这里插入图片描述

将6个服务启动后，如下图所示：
主：6380；从：6379、6381；
在这里插入图片描述

1、一主多从，读写分离
	//测试方法public Object getUserInfo(String username) {if (redisTemplate.opsForValue().get(username) == null) {System.out.println("未获取到缓存，新建用户信息.............");Map<String, Object> user = new HashMap<>();user.put("username", username);user.put("usercode", "zhangsan");user.put("sex", "男");user.put("createtime", new Date());redisTemplate.opsForValue().set(username, user);}return redisTemplate.opsForValue().get(username);}@Testpublic void testRedis() throws InterruptedException {System.out.println(userService.getUserInfo("1"));System.out.println(userService.getUserInfo("2"));System.out.println(userService.getUserInfo("3"));}

三台缓存服务器存储结果都是一致的，由此可见，哨兵模式是一主多从和读写分离模式。
在这里插入图片描述

2、主服务宕机，从服务升级主

哨兵模式另一目的就是当Master宏机后，从服务可快速自动升级为Master，不致于业务被中断。

当我们将主服务器6380停机之后，将会出现以下的内容。
三台哨兵控制台中都打印了，切换master的日志，可以看出主服务器已经变为6381这台服务器了。
在这里插入图片描述
对于我们的系统而言，由于缓存配置也是配置的哨兵的地址，主服务挂了之后，对于我们系统并无影响。

集群模式

集群模式一般需要6台服务器，3主3从，如下图共有6台缓存服务器。
在这里插入图片描述
分别启动6台服务器后，再cmd命令模式下执行一个命令，完成集群配置：

redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:7379 127.0.0.1:7380 127.0.0.1:7381 --cluster-replicas 1 -a 123456

集群启动后：
在这里插入图片描述
集群情况：在这里插入图片描述
主：6379、6381、6380；从：7379、7380、7381；

1、分布式存储
    @Testpublic void testRedis() throws InterruptedException {System.out.println(userService.getUserInfo("1"));System.out.println(userService.getUserInfo("2"));System.out.println(userService.getUserInfo("20000001"));System.out.println(userService.getUserInfo("20200002"));}

在这里插入图片描述
从结果看：
我们存储了4个值，1、2、2000001、20200002。
1,2------------> 主6380，从7381；
2000001----->主6381，从7379；
20200002—>主6379，从7380

2、高可用

我们关闭主节点6380，然后查看。

在这里插入图片描述
查看集群中各节点情况，6380显示fail。而7380已经变成了master节点了。

现在从缓存中读取前面缓存的4个值，虽然是异常提示：127.0.0.1:6380连接失败，但还是能获取到缓存内的值。（这里的异常是因为执行Test方法时，集群配置中有这台机器，初始化时连接不上的异常。若是一般在运行中的web项目不会出现这样的异常）
在这里插入图片描述
再次将6380启动起来后，6380变成了slave从节点。
6380启动日志：

[20520] 16 Jan 14:46:39.163 # Server initialized
[20520] 16 Jan 14:46:39.163 * DB loaded from append only file: 0.000 seconds
[20520] 16 Jan 14:46:39.163 * Ready to accept connections
[20520] 16 Jan 14:46:39.164 # Configuration change detected. Reconfiguring myself as a replica of c96d92167f25658f92b8e68fbe2cd641db0c9962
[20520] 16 Jan 14:46:39.164 * Before turning into a replica, using my master parameters to synthesize a cached master: I may be able to synchronize with the new master with just a partial transfer.
[20520] 16 Jan 14:46:39.165 # Cluster state changed: ok
[20520] 16 Jan 14:46:40.253 * Connecting to MASTER 127.0.0.1:7380
[20520] 16 Jan 14:46:40.253 * MASTER <-> REPLICA sync started
[20520] 16 Jan 14:46:40.256 * Non blocking connect for SYNC fired the event.
[20520] 16 Jan 14:46:40.256 * Master replied to PING, replication can continue...
[20520] 16 Jan 14:46:40.258 * Trying a partial resynchronization (request 3ce7caf46b989d9524c450b595a19e5d0c82b868:1).
[20520] 16 Jan 14:46:40.280 * Full resync from master: 609626e133d8d053640826b2da85b3789ed7ec02:5125
[20520] 16 Jan 14:46:40.280 * Discarding previously cached master state.
[20520] 16 Jan 14:46:40.419 * MASTER <-> REPLICA sync: receiving 419 bytes from master
[20520] 16 Jan 14:46:40.421 * MASTER <-> REPLICA sync: Flushing old data
[20520] 16 Jan 14:46:40.426 * MASTER <-> REPLICA sync: Loading DB in memory
[20520] 16 Jan 14:46:40.427 * MASTER <-> REPLICA sync: Finished with success
[20520] 16 Jan 14:46:40.442 * Background append only file rewriting started by pid 18008
[20520] 16 Jan 14:46:40.578 * AOF rewrite child asks to stop sending diffs.
[20520] 16 Jan 14:46:40.687 # fork operation complete
[20520] 16 Jan 14:46:40.697 * Background AOF rewrite terminated with success
[20520] 16 Jan 14:46:40.698 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
[20520] 16 Jan 14:46:40.700 * Background AOF rewrite finished successfully

在这里插入图片描述

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.hqwc.cn/news/415187.html

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

CTF CRYPTO 密码学-1

CTF CRYPTO 密码学-1

题目名称&#xff1a;enc 题目描述&#xff1a; 压缩包中含两个文件&#xff1a;一个秘钥d.dec&#xff0c;一个密文flag.enc 解题过程&#xff1a; Step1&#xff1a;这题是一个解密他题目&#xff0c;尝试openssl去ras解密 工具简介 在Kali Linux系统中&#xff0c;openss…
阅读更多...
深入理解 Kubernetes Ingress：路由流量、负载均衡和安全性配置

深入理解 Kubernetes Ingress：路由流量、负载均衡和安全性配置

Kubernetes Ingress 是 Kubernetes 集群中外部流量管理的重要组件。它为用户提供了一种直观而强大的方式&#xff0c;通过定义规则和配置&#xff0c;来控制外部流量的路由和访问。 1. 什么是 Ingress&#xff1f; 在 Kubernetes 中&#xff0c;Ingress 是一种 API 资源&#…
阅读更多...
C语言--质数算法和最大公约数算法

C语言--质数算法和最大公约数算法

文章目录 1.在C语言中&#xff0c;判断质数的常见算法有以下几种&#xff1a;1.1.试除法&#xff08;暴力算法&#xff09;&#xff1a;1.2.优化试除法&#xff1a;1.3.埃拉托色尼筛法&#xff1a;1.4.米勒-拉宾素性检验&#xff1a;1.5.线性筛法&#xff1a;1.6.费马小定理&am…
阅读更多...
LLM：Scaling Laws for Neural Language Models （中）

LLM：Scaling Laws for Neural Language Models （中）

核心结论 1&#xff1a;LLM模型的性能主要与计算量C&#xff0c;模型参数量N和数据大小D三者相关&#xff0c;而与模型的具体结构 (层数/深度/宽度) 基本无关。三者满足: C ≈ 6ND 2. 为了提升模型性能&#xff0c;模型参数量N和数据大小D需要同步放大&#xff0c;但模型和数…
阅读更多...
赋能客户不停歇，卓翼飞思职业院校无人智能装备师资培训圆满落幕

赋能客户不停歇，卓翼飞思职业院校无人智能装备师资培训圆满落幕

1月10日-15日&#xff0c;卓翼飞思在北京研发中心成功举办职业院校无人智能装备高级师资培训。来自湖南汽车工程职业学院&#xff08;以下简称&#xff1a;湖南汽车职院&#xff09;的10名师生&技术人员参与此次培训&#xff0c;针对无人智能集群应用开发进行系统性的培训及…
阅读更多...
重生奇迹MU快速升级

重生奇迹MU快速升级

1、前期&#xff0c;都是主线任务&#xff0c;我们必须要跟着主线任务走&#xff0c;前面的话升级一次需要的经验很少的&#xff0c;一天下来可以升级100级是轻轻松松的&#xff0c;主线任务是比较多的&#xff0c;我们跟着任务一直做差不多可以到150级&#xff0c;接下来就是后…
阅读更多...
flink学习之水位线

flink学习之水位线

什么是水位线 在事件时间语义下&#xff0c;我们不依赖系统时间&#xff0c;而是基于数据自带的时间戳去定义了一个时钟&#xff0c; 用来表示当前时间的进展。于是每个并行子任务都会有一个自己的逻辑时钟&#xff0c;它的前进是靠数 据的时间戳来驱动的。 我们可以把时钟也以…
阅读更多...
MySQL 基于创建时间进行RANGE分区

MySQL 基于创建时间进行RANGE分区

MySQL是一款广泛使用的关系型数据库。在MySQL中&#xff0c;大量数据场景提高查询效率是非常关键的&#xff0c;所以&#xff0c;对数据表进行分区是一个很好的选择。 在创建分区表之前&#xff0c;需要了解一下MySQL分区的基本概念。MySQL分区可以将一个大表分成多个小表&…
阅读更多...
Skydel 23.8新版本发布！GNSS模拟器完成首项实地路测项目

Skydel 23.8新版本发布！GNSS模拟器完成首项实地路测项目

奥本大学自动驾驶团队运用GNSS模拟器完成首项实地路测项目 奥本大学与最近与阿拉巴马州伯明翰的巴伯赛车运动公园合作进行道路测试&#xff0c;该车在没有任何人工干预的情况下成功绕赛道完成了一圈&#xff0c;这也是印地自动驾驶挑战赛中车辆首次在美国专业赛道上完成一圈。…
阅读更多...
Docker（二）安装指南：主要介绍在 Linux 、Windows 10 和 macOS 上的安装

Docker（二）安装指南：主要介绍在 Linux 、Windows 10 和 macOS 上的安装

作者主页&#xff1a; 正函数的个人主页 文章收录专栏&#xff1a; Docker 欢迎大家点赞 &#x1f44d; 收藏 ⭐ 加关注哦&#xff01; 安装 Docker Docker 分为 stable test 和 nightly 三个更新频道。 官方网站上有各种环境下的 安装指南&#xff0c;这里主要介绍 Docker 在…
阅读更多...
Java项目：11 Springboot的垃圾回收管理系统

Java项目：11 Springboot的垃圾回收管理系统

作者主页&#xff1a;舒克日记 简介&#xff1a;Java领域优质创作者、Java项目、学习资料、技术互助 文中获取源码 项目介绍 功能介绍 本系统通过利用系统的垃圾回收流程&#xff0c;提高垃圾回收效率&#xff0c;通过垃圾回收的申请&#xff0c;增删改查&#xff0c;垃圾运输申…
阅读更多...
docker部署项目，/var/lib/docker/overlay2目录满了如何清理？

docker部署项目，/var/lib/docker/overlay2目录满了如何清理？

docker部署项目&#xff0c;/var/lib/docker/overlay2目录满了如何清理&#xff1f; 一、问题二、解决1、查看 /var/lib/docker 目录&#xff08;1&#xff09;、containers 目录&#xff08;2&#xff09;、volumes 目录&#xff08;3&#xff09;、overlay2 目录 2、清理&…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023