【速成Redis】04 Redis 概念扫盲:事务、持久化、主从复制、哨兵模式

前言:

前三篇如下:

【速成Redis】01 Redis简介及windows上如何安装redis-CSDN博客

【速成Redis】02 Redis 五大基本数据类型常用命令-CSDN博客

【速成Redis】03 Redis 五大高级数据结构介绍及其常用命令 | 消息队列、地理空间、HyperLogLog、BitMap、BitField-CSDN博客

该篇04是速成系列的完结篇,主要对redis一些重要概念进行扫盲性认知,如事务、持久化、主从复制、哨兵模式。 道阻且长,学完这4篇只能称得上是刚入门redis。剩下还有很多路要走。


目录

[一、redis 事务](#一、redis 事务)

1.认知:不是传统的事务

2.redis可以保证以下3点

3.实操

二、持久化

1.RDB

[- 可以通过使用配置文件中的save参数来配置:](#- 可以通过使用配置文件中的save参数来配置:)

[- 通过手工save命令](#- 通过手工save命令)

[- 快照文件缺点:](#- 快照文件缺点:)

2.AOF

[- 原理:](#- 原理:)

[- 开启AOF的方式:](#- 开启AOF的方式:)

三、主从复制

四、哨兵模式


一、redis 事务

1.认知:不是传统的事务

redis的事务和我们之前学习的关系型数据库的事务是不太一样。

在关系型数据库中,事务是一个原子操作,要么全部执行成功,要么全部执行失败。

而在redis中,事务并不能保证所有命令都会执行成功。
redis所支持的支持事务,也就是可以在一次请求中执行多个命令,reids中的事务主要通过MULTI和EXEC实现的。

MULTI命令用来开启一个事务。事务开启后,所有命令会被放入一个队列中,最后通过一个EXEC命令来执行事务中的所有命令。


2.redis可以保证以下3点

1.在发送EXEC命令之前,所有命令都会被放入到一个队列中缓存起来,不会立即执行

2.在收到EXEC命令之后,事务开始执行,事务中任何一个命令执行失败,其他命令依然会回执行。

3.在事务执行过程中,其他客户端提交的命令请求,并不会被插入到事务的执行命令序列中。


3.实操

1.MUTLI开启事务、EXEC提交事务

2.验证事务的特性:

先创建三个新的键:k3、k4、k5

开启事务并且,让其自增,很显然k4的value无法解析为数字,无法自增

结束事务,开始执行命令:

可以看到第二个命令执行失败,别的键已经自增,k4没有变化


二、持久化

持久化是redis一个非常重要的功能,因为redis是基于内存的数据库,如果没有持久化的话,一旦服务器重启或者断电,那么之前所有的数据都会丢失。


redis持久化主要有两种方式:


1.RDB

是指在指定时间间隔内,将内存中的数据快照写入磁盘,它是某一个时间点上数据的完整副本。

- 可以通过使用配置文件中的save参数来配置:

如图,找到redis.windows.conf配置文件

把sava命令修改

save x y:在x秒时候至少y个键被修改进行一次快照

(根据自己电脑的配置和使用情况修改)

带着新配置文件启动redis服务

在客户端可以检查配置


- 通过手工save命令

除了用配置文件触发快照之外,还可以使用save命令来手工触发快照。

依旧是同一个配置文件,这里是快照储存路径。
执行完修改之后,手工save。


在快照保存处可以看到rdb文件了。


- 快照文件缺点:

**如果服务机器在最后一次快照之后宕机了,那么最后一次快照之后的修改内容都会丢失掉。**所以RDB更适合用来做备份, 比如可以每天凌晨时,通过crontab来执行一次save 命令,然后将快照文件备份到其他地方,保证数据安全。

在生产环境中,我们为redis开辟的内存区域都比较大,**那么内存中的数据同步到硬盘这个过程,就会持续比较长的时间,这段时间redis处于一个阻塞状态,**显然是不行的,这段时间内redis都是处于一个阻塞状态,不能接受任何请求。

**于是redis提供了一个bgsave的命令,这个命令会单独创建一个子进程,来负责内存数据写入硬盘。**这时候主进程就可以接受请求了,但这个过程中还是会有一定的性能损耗。因为fork一个子进程是需要时间的,这段时间redis还是不能处理任何请求,无法做到秒级快照。

2.AOF

- 原理:

为了解决快照文件的这个问题,redis提供了另一种文件持久化方式:AOF(字面意思是追加文件),**它的原理是在执行写命令时,不仅会将命令写入到内存中,也会讲命令写到一个文件中,这个文件就是AOF文件。**它会以日志形式记录整个写操作,当redis重启时,它就会重新通过AOF文件中的命令,来在内存中重建整个数据库内容。

- 开启AOF的方式:

如图,依旧是那个配置文件,把appendonly后的no改为yes


三、主从复制

主从复制是指将一台redis服务器节点复制到另一台redis服务器。

也叫主节点、从节点:

一个主节点可以有多个从节点,而一个从节点只可以有一个主节点。
核心作用:主节点的变化能自动同步到从节点上。

数据复制是单向的,只能由主节点到从节点。一般来说,主节点负责写操作,从节点负责读操作。主节点会将自己的数据变化,通过异步的方式发送给从节点,从节点接收到主节点的数据之后,更新自己的数据,这样就达到了数据一致的目的。


实际动手配置主从复制:主节点不需要修改任何配置,要修改的是从节点的配置。

命令配置方式有两种:一种是通过命令行执行命令。

slaveof方式指定主节点的ip和端口,这种方式不常用,了解即可,

另一种是通过配置文件(常用),实操过多这里不着重介绍。该篇主要扫盲,了解什么是主从复制。


四、哨兵模式

导入:

我们可以通过主从复制,为一个主节点,配置两个从节点,形成一主两从的redis集群,实现了一定程度上的高可用。相比单节点的redis来说有了很大的提升。

但是这个集群还是有一定问题的,主节点宕机了,我们还是需要手工去把另一台从节点提升为主节点,还是要人工干预,不是真正的高可用。

有什么方法可以实现自动的故障转移呢?这就是redis哨兵模式!


哨兵会以一个独立的进程,运行在redis集群中,用来监控redis的各个节点是否运行正常,主要用来执行下面几个功能:

**1.监控:**通过不断地发送通知,检查redis节点是否正常

**2.通知:**如果发现某个节点出问题了,哨兵就会通过发布订阅模式,来通知其他节点

**3.自动故障转移:**当主节点不能正常工作时,哨兵就会开启一个自动故障转移的操作,它会将一个从节点升级为一个新的主节点。然后再将其他的从节点指向新的主节点。

ps:哨兵本身也是一个进程,它自己也会有单节点故障的问题.

所以一般在实际的生产环境,会使用三个哨兵节点保证高可用,这三个哨兵节点会通过选举方式,选出领导者,然后由领导者来监控其他节点。如果领导者挂了,那么其他哨兵节点会重新选举出一个领导者,这样就可以保证哨兵节点的高可用了。

相关推荐
神仙别闹20 分钟前
基于java的改良版超级玛丽小游戏
java
你的微笑,乱了夏天32 分钟前
linux centos 7 安装 mongodb7
数据库·mongodb
黄油饼卷咖喱鸡就味增汤拌孜然羊肉炒饭43 分钟前
SpringBoot如何实现缓存预热?
java·spring boot·spring·缓存·程序员
工业甲酰苯胺43 分钟前
分布式系统架构:服务容错
数据库·架构
暮湫1 小时前
泛型(2)
java
超爱吃士力架1 小时前
邀请逻辑
java·linux·后端
南宫生1 小时前
力扣-图论-17【算法学习day.67】
java·学习·算法·leetcode·图论
转码的小石1 小时前
12/21java基础
java
李小白661 小时前
Spring MVC(上)
java·spring·mvc
GoodStudyAndDayDayUp2 小时前
IDEA能够从mapper跳转到xml的插件
xml·java·intellij-idea