7、Redis-事务、持久化、内存淘汰机制和过期key处理

news2024/11/24 15:37:43

一、事务

二、持久化

三、内存淘汰机制

四、过期key处理

一、事务

Redis的事务本质上就是一个批量执行命令的操作。分为三个步骤：

开始事务：multi
命令入队：正常输入命令即可
执行事务（依次执行命令）：exec

执行过程中某条命令失败，事务既不会回滚，也不会停止。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name Trxcx
QUEUED // 命令入队而不是立即被执行
127.0.0.1:6379> set age 21
QUEUED
127.0.0.1:6379> incr age
QUEUED
127.0.0.1:6379> incr name // 错误的命令正常入队
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> get age
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (integer) 22
4) (error) ERR value is not an integer or out of range
5) "Trxcx"
6) "22" 
// 即使中间某条命令出错，前面的命令也没有回滚，后面的命令也没有停止。
// 整个事务就是在依次执行这些命令

二、持久化

Redis会不定时地将数据持久化到硬盘中，当Redis启动时，会把硬盘中的数据加载到内存中。

Redis持久化机制共有3种：

1、RDB（Redis DataBase ）：快照方式

将内存中的数据以快照的方式写入二进制文件，默认为dump.rdb【Redis安装目录下】中。触发RDB持久化的机制分为手动触发和自动触发。

手动触发：

①使用save命令。阻塞Redis服务器直到RDB过程完成，数据较多时会长时间阻塞。

②使用bgsave命令。执行fork指令创建子进程实现RDB持久化。【更建议使用】

自动触发：

使用save进行配置。格式为：save m n。

表示m秒内数据集存在n次修改则会触发bgsave。

save 300 10：表示300秒内超过10个key被修改，则触发RDB过程进行持久化

2、AOF（Append Only File ）：文件追加方式

AOF 日志是一个增量日志文件，它会记录执行的命令。因此，重启时再重新执行AOF文件中的命令，就可以达到恢复数据的目的。

Redis默认是不开启AOF的，通过修改配置文件进行配置。redis 开启AOF - 简书 (jianshu.com)

AOF共有3种配置策略，

appendfsync always：立即同步命令到磁盘，效率慢但保证完全持久化
appendfsync everysec：每秒同步一次，效率和持久化效果居中【更推荐使用】
appendfsync no：依赖操作系统，通常每30s同步一次

AOF Rewrite：AOF 文件记录了每个写操作的日志，以确保数据持久性。随着时间的推移，AOF 文件会不断增大。为了解决这个问题，Redis通过AOF Rewrite 操作创建一个新的 AOF 文件，其中只包含当前数据库状态的最小命令集，然后将旧的 AOF 文件替换为这个新文件。

总结：RDB持久化文件更小，启动速度更快；AOF则在持久化的效果方面更胜一筹。

3、混合持久化方式

Redis同时开启RDB和AOF，在某时刻T1进行了RDB持久化，在下一次RDB持久化（T3）之前，Redis服务器于T2时刻重启。

此时恢复数据时，T1之前的数据以 RDB 的形式写入文件的开头（全量恢复），T1到T2之间的数据则通过执行AOF文件存储的操作命令（增量恢复），以此达到速度和持久化效率的平衡。

即以 RDB 作为全量备份，AOF 作为增量备份。

4、持久化机制选择

对安全性要求高：RDB+AOF
可以容忍数据丢失：RDB
不推荐单独AOF，可能出现bug。

关于Redis启动：

AOF和RDB同时存在时优先加载AOF；某一个存在时就加载那一个。

都不存在或加载成功时则启动成功，存在AOF或者RDB但加载失败时则启动失败。

三、内存淘汰机制

LRU：Least recently used。最近最少被使用到的key被淘汰。在可选的淘汰对象中，上一次使用时间距离现在最久的key被淘汰。【recently---关注时间】
LFU：Least Frequently Used。最不经常使用的key被淘汰。在可选的淘汰对象中，使用次数最少的key被淘汰。【Frequently ---关注使用频次】
TTL：设置了过期时间且快要过期的key被淘汰。
随机淘汰。