流程图解:
我们可以通过查看日志文件来了解流程
注意:bgsave命令是针对sava阻塞问题做的优化,Redis内部所有涉及到RDB操作都采用bgsave的方式,save命令
可以放弃使用
bgsave配置
-
stop-writes-on-bgsave-error yes
-
说明:后台存储过程中如果出现错误现象,是否停止保存操作
-
通常默认为
开启状态
我们会遇到这样的问题:
反复执行保存指令,忘记执行了怎么办?不知道数据产生了多少变化,何时保存?
我们可以通过配置解决上述问题
配置
-
save second changes
-
作用
-
满足限定时间范围内key的变化数量达到
指定数量
即执行持久化 -
参数
-
second :
监控时间范围
-
changes:
监控key的变化量
-
位置
-
在conf文件中进行配置
-
范例
-
save 900 1
-
save 300 10
-
save 60 10000
配置完成后,只要在规定seconds内key的变化次数达到changes,redis就会自动执行bgsave指令,如果规定时间内
key的变化没有达到changes,则会重新计时
演示:
我们进入conf文件进行配置
启动redis,先添加1个key观察,rdb文件是否出现
文件并没有出现,说明bgsave指令没有被执行
在10s内添加2个key
试一试
rdb文件出现,说明bgsave指令已被执行
====================================================================
在我们进行配置以后,每一个指令之后的都对应着一个结果,而结果如果对save产生影响就必须满足以下两个条件
-
对数据产生了
影响
(get key这种不对数据产生影响的就会被忽略) -
对数据真正产生了影响(例如
原来age=18,执行set age=19之后又执行set age=18
,age的值并没有发生变化,故指令被忽略)
注意:
-
save配置要根据实际业务情况进行设置,频度过高或过低都会出现性能问题,结果可能是灾难性的
-
save配置中对于second与changes设置通常具有互补对应关系,尽量不要设置成包含性关系
-
save配置启动后执行的是bgsave操作
=================================================================================
| 方式 | save指令 | bgsave指令 |
| :-: | :-: | :-: |
| 读写 | 同步 | 异步 |
| 阻塞客户端指令 | 是 | 否 |
| 额外内存消耗 | 否 | 是 |
| 启动新进程 | 否 | 是 |
RDB特殊启动方式
-
服务器运行过程中重启
-
debug reload
-
关闭服务器时指定保存数据
-
shutdown save
RDB优点
-
RDB是一个紧凑压缩的二进制文件,存储效率较高
-
RDB内部存储的是redis在某个时间点的数据快照,非常适合用于数据备份,全量复制等场景
-
RDB恢复数据的速度要比AOF快很多
-
应用:服务器中每X小时执行bgsave备份,并将RDB文件拷贝到远程机器中,用于灾难恢复
RDB缺点
-
RDB方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能性丢失数据
-
bgsave指令每次要运行fork操作创建子进程,要牺牲掉一些性能
-
Redis的众多版本中未进行RDB文件格式的版本统一,有可能出现各版本服务之间数据格式无法兼容现象
=======================================================================
上面我们讲的RDB基于快照思想,每次读写都是全部数据,当数据量巨大时,效率非常低,并且基于fork创建的子进程也会产生额外消耗,并且需要达到一定条件才可进行保存,一旦遇到宕机,数据就存在丢失的风险
解决思路
-
不写全数据,仅
记录部分
数据 -
改记数据为
记录操作记录
-
对所有的操作均进行记录,排除丢失数据的风险
===========================================================================
-
AOF(append only file)持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令达到
-
恢复数据的目的。与RBD相比可以简单描述为改记录数据为记录数据产生的过程
-
AOF的主要作用是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式
===============================================================================
当我们发送指令给服务器,服务器接收到指令并没有马上记录,而是将指令放到AOF写命令刷新缓存区
,缓冲区满,将直接把命令同步到AOF文件
中
至于一次写过去多少条,多久写一次,我们通过配置策略来解决
⭐️1.2.3 AOF写数据三种策略(appendfsync)
=============================================================================================
-
always(每次)
-
每次写入操作均同步到AOF文件中,数据零误差,性能较低
-
everysec(每秒)
-
每秒将缓冲区中的指令同步到AOF文件中,数据准确性较高,性能较高
-
在系统突然宕机的情况下丢失1秒内的数据
-
no(系统控制)
-
由操作系统控制每次同步到AOF文件的周期,整体过程不可控
========================================================================
-
配置
-
appendonly yes|no
-
作用
-
是否开启AOF持久化功能,默认为不开启状态
-
配置
-
appendfsync always|everysec|no
-
作用
-
AOF数据策略
-
配置
-
appendfilename filename
-
作用
-
AOF持久化文件名,默认文件名为appendonly.aof,建议配置为appendonly-端口号.aof
-
配置
-
dir
-
作用
-
AOF持久化文件保存路径,与RBD持久化文件保持一致
========================================================================
配置完成后重启redis服务
可以看到AOF持久化文件已经生成
我们尝试存储一些数据并观察文件的变化
进入持久化文件
我们发现我们每一步有效操作的步骤都被记录在文件中
=================================================================================
我们执行以上指令会发现,set name zs 和 set name ls 在写数据时实际上是不用执行的incr num也可以合并为1条指令,AOF提供这样的功能
===========================================================================
随着命令不断写入AOF,文件会越来越大
,为了解决这个问题,Redis引入了AOF重写机制
压缩文件体积,AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。
简单说就是将对同一个数据的若干个命令执行结果转化成最终结果数据对应的指令进行记录
AOF重写的规则
-
进程内
已超时的数据不再写入文件
-
忽略无效指令
,重写时使用进程内数据直接生成,这样新的AOF文件只保留最终数据的写入命令 -
如del key1、hdel key2、srem key3、set key4 111、set key4 222等
-
对同一数据的多条写命令
合并
为一条命令 -
如lpush list1 a、lpush list1 b、lpush list1 c可转化为:lpush list1 a b c
-
为防止数据量过大造成客户端缓冲区溢出,对list、set、hash、zset等类型,每条指令对多写入64个元素
===============================================================================
-
手动重写
-
bgrewriteaof
-
自动重写
-
auto-aof-rewrite-min-size size
-
auto-aof-rewrite-percentage percentage
未指定重写之前
AOF将操作都记录了下来
手动重写:
查看aof文件
我们看到只有set name 456在其中,set name 123 set name 235等无效操作没有被记录
=============================================================================
| 持久化方式 | RDB | AOF |
| :-: | :-: | :-: |
| 占用存储空间 | 小(数据级:压缩) | 大(指令级:压缩) |
| 存储速度 | 慢 | 快 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 有可能丢失 | 依据策略决定 |
| 资源消耗 | 高/重量级 | 低/轻量级 |
| 启动优先级 | 低 | 高 |
================================================================================
====================================================================
一般来说,事务是必须满足4个条件
(ACID)::
原子性(Atomicity,或称不可分割性)、一致性(Consistency)、隔离性(Isolation,又称
独立性)、持久性(Durability)。
-
**原子性:**一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
-
**一致性:**在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则,这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
-
**隔离性:**数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括读未提交(Read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(Serializable)。
-
**持久性:**事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。
redis事务就是一个命令执行的队列,将一系列预定义命令包装秤一个整体(一个队列)。当执行时,一次性按照添加顺序依次执行,中间不会被打断或干扰
===========================================================================
-
开启事务
-
multi
-
作用
-
设定事务的开启位置,此指令执行后,后续的所有指令均加入到事务中
-
执行事务
-
exec
-
作用
-
设定事务的结束位置,同时执行事务。与multi成对出现,成对使用
-
取消事务
-
discard
-
作用
-
终止当前事务的定义,发生在multi之后,exec之前
加入事务的命令暂时进入到任务队列中,并没有立即执行,只有执行exec命令才开始执行
===========================================================================
假定我们有一个set指令,服务器接收到之后会先做判断,判断set指令是否处于事务状态
-
不在事务状态:识别指令,如果是普通指令就直接执行并返回执行结果,如果是事务指令(MULTI),会直接创建事务队列,然后返回“OK”结果
-
在事务状态:识别指令,如果是普通指令,就将该指令加入队列,如果是事务指令(EXEC)则会直接执行事务,事务队列中的指令会挨个执行,执行完毕后返回执行结果并销毁事务队列,如果是事务指令(DISCARD),则会直接销毁事务队列,返回结果
事务执行流程图解
=============================================================================
1.如果定义事务的过程中,命令格式输入错误怎么办?
-
语法错误
-
指命令书写格式有误
-
处理结果
-
如果定义的事物中所包含的命令存在语法错误,整体事务中所有命令
均不会执行
。包括那些语法正确的命令
2.如果定义事务的过程中,命令执行出现错误怎么办?
-
运行错误
-
指命令格式正确,但是无法正确的执行,例如对list进行incr操作
-
处理结果
-
能够正确运行的命令会执行,
运行错误的命令不会被执行
注意:已经执行完毕的命令对应的数据不会自动实现回滚,有些操作具有连贯性的,当我们其中一行指令执行错误,
后面指令的结果会受到影响,这就比较难受了,需要程序员自己在代码中实现回滚,因为这种原因,redis的事务在
企业级开发中用的较少一些
=====================================================================
业务场景1
天猫双11热卖过程中,对已经售空的货物追加补货,4个业务员都有权限进行补货。补货的操作可能是一系列的操作,牵扯到多个连续操作,如何保障不会重复操作?
业务分析1
-
多个客户端有可能
同时操作同一组数据
,并且该数据一旦被操作修改后,将不适用于继续操作 -
在操作之前锁定要操作的数据,一旦发生变化,终止当前操作
解决方案1
-
对key添加监视锁,在执行exec前如果key发生了变化,终止事务进行
-
watch key1 [key2…]
-
取消对所有key的监视
-
unwatch
在执行exec之前,我们让另一个客户端修改name的值,发现执行exec之后结果为nil,事务队列中的所有指令都被取消,可以看出,watch指令监控的东西一旦发生改变,事务将不再执行,除非在开启事务之前unwatch,取消监控
业务场景2
天猫双11热卖过程中,对已经售空的货物追加补货,且补货完成。客户购买热情高涨,3秒内将所有商品购买完毕。本次补货已经将库存全部清空,如何避免最后一件商品不被多人同时购买?【超卖问题】
业务分析2
-
使用
watch
监控一个key有没有改变已经不能解决问题,此处要监控的是具体数据 -
虽然
redis是单线程的
,但是多个客户端对同一数据同时进行操作时,如何避免不被同时修改?
解决方案2
-
使用setnx设置一个公共锁
-
setnx lock-key value
-
作用
-
利用setnx命令的返回值特征,有值则返回设置失败,无值则返回设置成功
-
对于返回设置成功的,拥有控制权,进行下一步的具体业务操作
-
对于返回设置失败的,不具有控制权,排队或等待
-
操作完毕通过del操作释放锁
上述解决方案是一种设计概念,依赖规范保障,具有风险性(锁必须一致,如果设置锁为lock-num那么之后是用的
锁都应该是lock-num)
操作演示:
我们对num加锁,对其进行操作,如果此时另一个用户也想获取锁就会失败
==========================================================================
业务场景1
依赖分布式锁的机制,某个用户操作时对应的客户端宕机,但是它已经获得了锁,其他客户端需要它释放锁才能继续工作,如何解决?
业务分析1
-
由于锁操作由用户控制加锁解锁,必定会存在加锁后未解锁的风险
-
需要解锁操作不能仅依赖用户控制,系统级别要给出对应的保底处理方案
我们采取的方案就是给锁加一个时效
解决方案1
-
使用expire为锁key添加时间限定,到时不释放,放弃锁
-
expire lock-key second (设置秒)
-
pexpire lock-key milliseconds (设置毫秒)
演示:
此时另一客户不断获取锁,终于在设定的20s之后获取到了锁
======================================================================
========================================================================
Redis是一种内存级数据库,所有数据均存放在内存中,内存中的数据可以通过TTL指令获取其状态
-
XX:具有时效性的数据
-
-1:永久有效的数据
-
-2:已经过期的数据或被删除的数据或为定义的数据
时效性数据的存储结构
redis会开放出一个空间名叫expires
,它是哈希结构
的,存放的数据左边是16进制的地址
,而右边就是过期时间
,一个地址和一个过期时间相对应
数据删除策略的目标:
在内存占用与CPU占用之间寻找一种平衡,顾此失彼都会造成整体redis性能的下降,甚至引发服务器宕机或内存泄露
==========================================================================
==========================================================================
==========================================================================
-
数据
到达过期时间
,不作处理
,等下次访问该数据时再做处理(get name) -
如果未过期,返回数据
-
如果过期,删除数据,返回不存在,内部会触发expirelfNeeded()函数,在任何获取数据的操作之前内部都将执行这个操作,expirelfNeeded()便是检查数据是否过期的
-
优点、节约CPU性能,发现必须删除的时候才删除
-
缺点:内存压力很大,出现长期占用内存的数据
总结:以空间换时间
==========================================================================
通过对比我们发现,无论是定时删除还是惰性删除都显得太过极端,有没有一种折中方案呢?
在redis的16个数据库中每一个数据库中都会存在一个expires,里面存放所有的过期数据地址
和过期时间
定期删除的策略是这样的:
当redis启动服务完成初始化的时候,它会去读取server.hz
的值,这个值默认为10
- redis每秒执行server.hz次serverCron()进行定时轮询,serverCron会去调用databasesCron()方法,对
redis的每个库进行轮询,访问expires的信息,对他们执行activeExpireCycle()进行数据检查
-
activeExpireCycle()方法对每个expires[*]逐一进行检测,每次执行250ms/server.hz次
-
activeExpireCycle()的执行策略是对每个expires[*]检测时,随机挑选W个key检测,如果key超时,就直接
删除key,如果一轮中超时的key的数量>Wx25%,则循环该过程,如果<Wx25%,则检查下一个数据库的expires,16
个数据库循环进行
-
简单地说我们可以理解为抽奖,一直对16个数据库进行轮询,删除过期数据,对于某一个数据库如果过期数据>
-
抽出总量的1/4则继续抽奖,否则就去下一个数据库继续抽奖
-
W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值
-
参数current_db用于记录activeExpireCycle进入哪一个expires[*]执行
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
总结
我们总是喜欢瞻仰大厂的大神们,但实际上大神也不过凡人,与菜鸟程序员相比,也就多花了几分心思,如果你再不努力,差距也只会越来越大。实际上,作为程序员,丰富自己的知识储备,提升自己的知识深度和广度是很有必要的。
Mybatis源码解析
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值
- 参数current_db用于记录activeExpireCycle进入哪一个expires[*]执行
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。[外链图片转存中…(img-bbpRlPxh-1713534790029)]
[外链图片转存中…(img-As9ohLMx-1713534790032)]
[外链图片转存中…(img-dCve2RTz-1713534790035)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
总结
我们总是喜欢瞻仰大厂的大神们,但实际上大神也不过凡人,与菜鸟程序员相比,也就多花了几分心思,如果你再不努力,差距也只会越来越大。实际上,作为程序员,丰富自己的知识储备,提升自己的知识深度和广度是很有必要的。
Mybatis源码解析
[外链图片转存中…(img-iOsmq1jB-1713534790037)]
[外链图片转存中…(img-e9jLhBiX-1713534790039)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!