做视频哪个网站收入高,详情页设计英文翻译,网页设计网站题目,网页设计代码意思目录
# 概念
1. RDB持久化
1.1 备份是如何执行的#xff08;RDB过程#xff09;
1.2 配置文件信息
1.3 RDB持久化操作
1.4 RDB优势
1.5 RDB劣势
1.6 RDB做备份
2. AOF持久化
2.1 AOF开启及使用
2.2 异常恢复
2.3 配置文件操作
2.4 AOF持久化流程
2.5 优点
2.6…目录
# 概念
1. RDB持久化
1.1 备份是如何执行的RDB过程
1.2 配置文件信息
1.3 RDB持久化操作
1.4 RDB优势
1.5 RDB劣势
1.6 RDB做备份
2. AOF持久化
2.1 AOF开启及使用
2.2 异常恢复
2.3 配置文件操作
2.4 AOF持久化流程
2.5 优点
2.6 劣势 # 概念 redis持久化概念 redis是我们的内存数据存在内存中的但是redis也可以写道硬盘中去这个过程就叫持久化 RDB与AOF的优先级 AOF和 RDB 同时开启系统默认取 AOF的数据数据不会存在丢失
1. RDB持久化 概念 就是在指定的时间间隔中将内存中的数据集快照写入到磁盘中硬盘是磁盘的一种比如每个10秒写入一次再过10秒写入一次等
1.1 备份是如何执行的RDB过程 Redis会单独创建fork一个子进程来进行持久化会先将数据写入到一个临时文件中待持久化过程都结束了再用这个临时文件替换上次持久化好的文件。整个过程中主进程是不进行任何I0操作的这就确保了极高的性能如果需要进行大规模数据的恢复且对于数据恢复的完整性不是非常敏感那RDB方式要比AOF方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失 Fork Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据变量、环境变量、程序计数器等数值都和原进程一致但是是一个全新的进程并作为原进程的子进程 在 Linux 程序中fork()会产生一个和父进程完全相同的子进程但子进程在此后多会 exec 系统调用出于效率考虑Linux 中引入了“写时复制技术” 一般情况父进程和子进程会共用同一段物理内存只有进程空间的各段的内容要发生变化时才会将父进程的内容复制一份给子进程
dump.rdb文件 1.2 配置文件信息
配置文件存在vim /etc/redis.conf 一、stop-writes-on-bgsave-error yes当redis无法写入磁盘直接关闭redis写操作推荐yes 二、rdbcompression yes对于存储到磁盘中的快照设置是否进行压缩存储
对于存储到磁盘中的快照设置是否进行压缩存储。如果是redis会采用LZF算法进行压缩
如果不想消耗CPU进行压缩可以设置为关闭此功能推荐yes 三、rdbchecksum检查完整性存储快照后让redis使用CRC64算法进行数据校验
推荐yes 四、Save秒钟写操作次数
在 Redis 的配置文件中save 命令用于配置数据库的 RDBRedis Database持久化策略。它定义了在特定时间间隔内如果发生了一定数量的键改变Redis 将触发持久化操作将数据保存到磁盘中。
这三条配置定义了 Redis 在以下条件下触发持久化的规则
save 900 1: 时间间隔: 900秒15分钟。键改变数量: 至少1个键。解释: 如果在900秒内至少有1个键发生了变化被修改、删除或新增Redis 将触发一次持久化操作将数据保存到磁盘。save 300 10: 时间间隔: 300秒5分钟。键改变数量: 至少10个键。解释: 如果在300秒内至少有10个键发生了变化Redis 将触发一次持久化操作将数据保存到磁盘。save 60 10000: 时间间隔: 60秒1分钟。键改变数量: 至少10000个键。解释: 如果在60秒内至少有10000个键发生了变化Redis 将触发一次持久化操作将数据保存到磁盘。 运行原理 Redis 会在后台持续监视键的变化。如果在指定的时间间隔内键的变化次数达到设置的数量Redis 就会创建一个 RDB 快照。这个快照包含当前数据库状态的一个副本并将其写入磁盘以便于恢复数据。配置多个 save 条目可以根据不同的条件灵活地触发持久化操作。 配置的意义和影响 灵活的持久化策略: 不同时间间隔和键改变数量的配置使得 Redis 能够灵活处理持久化操作。在频繁变化的情况下如 save 60 10000它能快速保存数据而在变化较少的情况下如 save 900 1则不会频繁触发持久化减少性能开销。数据持久化: 这些配置确保了 Redis 的数据能够定期持久化到磁盘中以防止数据丢失。性能权衡: 更频繁的持久化会导致更多的磁盘 I/O从而影响性能而较少的持久化则可能在崩溃时导致更多的数据丢失。 五、save VS bgsave save 工作机制 同步操作: save 是一个同步操作阻塞当前 Redis 实例直到保存过程完成。数据持久化: 它会生成一个 RDB (Redis Database) 快照文件将当前的内存数据保存到磁盘。优缺点 优点: 操作简单适合在 Redis 启动期间使用确保启动时的数据被持久化。缺点: 由于是同步操作期间 Redis 将不能处理其他请求可能导致性能问题尤其在数据量大时。典型使用场景 紧急保存: 在进行数据恢复操作之前确保数据不丢失。开发和调试: 当需要手动触发保存数据以查看具体状态时。示例SAVE bgsave 工作机制 异步操作: bgsave 是一个异步操作Redis 主进程会 fork 一个子进程来执行数据持久化。数据持久化: 子进程会生成一个 RDB 快照文件将当前的内存数据保存到磁盘而主进程继续处理客户端的请求。优缺点 优点: 不阻塞 Redis 主进程允许 Redis 继续处理其他请求适合在运行时定期保存数据。缺点: fork 操作在数据量大时可能会占用较多的系统资源并且对系统内存开销较大。典型使用场景 定期备份: 在运行时定期进行数据备份减少持久化对性能的影响。大规模应用: 适合需要频繁持久化数据且不希望阻塞请求处理的大规模应用。示例BGSAVE 主要区别总结
特性savebgsave操作模式同步异步阻塞行为阻塞非阻塞系统资源较少较多执行时机手动手动或自动配置性能影响高低
1.3 RDB持久化操作 设置key 写入后查询证明做了持久化操作 1.4 RDB优势
适合大规模的数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快
1.5 RDB劣势
Fork 的时候内存中的数据被克隆了一份大致2倍的膨胀性需要考虑
虽然 Redis.在 fork 时使用了写时拷贝技术但是如果数据庞大时还是比较消耗性能
在备份周期在一定间隔时间做一次备份所以如果 Redis 意外 down 掉的话就会丢失最后一次快照后的所有修改
1.6 RDB做备份 我们在移除前先做一个插入操作以上操作后重新启动redis在删除dump文件后进入复制的文件中查看这时候就有之前设置的3个key了save 20 3这个是备份恢复过程 2. AOF持久化 概念 Append Only File在redis中的另一种持久化的方式 以日志的形式来记录每个写操作增量保存将 Redis 执行过的所有写指令记录下来读操作不记录只许追加文件但不可以改写文件redis启动之初会读取该文件重新构建数据换言之redis 重启的话就根据日志文件的内容将写指令从前到后执行-次以完成数据的恢复工作
2.1 AOF开启及使用 开启后就会有默认文件appendonly yes 使用在开启完后在redis中set入值这时候文件的大小发生了变化 2.2 异常恢复
修改默认的 appendonly no改为 yes
如遇到 AOF文件损坏通过/usr/local/bin/redis-check-aof--fix appendonly.aof 进行恢复
作用备份被写坏的 AOF 文件
恢复重启 redis然后重新加载
2.3 配置文件操作
1. AOF同步步率设置
appendfsync always始终同步每次Redis的写入都会立刻记入日志虽然性能较差但数据完整性比较好
appendfsync everysec每秒同步每秒记入日志一次如果宕机本秒的数据可能丢失
appendfsync noredis不主动进行同步把同步时机交给操作系统 2. rewrite压缩 rewrite是什么 AOF 采用文件追加方式文件会越来越大为避免出现此种情况新增了重写机制当AOF 文件的大小超过所设定的阈值时Redis 就会启动 AOF 文件的内容压缩 只保留可以恢复数据的最小指令集可以使用命令 bgrewriteaof 重写原理如何实现重写 AOF 文件持续增长而过大时会 fork 出一条新进程来将文件重写也是先写临时文件最后renameredis4.0 版本后的重写是指上就是把 rdb 的快照以二级制的形式附在新的 aof头部作为已有的历史数据替换掉原来的流水账操作
3. no-appendfsync-on-rewrite AOF 是否继续同步数据到磁盘
在 Redis 中no-appendfsync-on-rewrite 配置选项与 AOFAppend Only File持久化和 RDBRedis Database持久化的相互作用相关。这个选项控制了在执行 RDB 快照的同时AOF 是否继续同步数据到磁盘
no-appendfsync-on-rewrite 的值为 no 时默认情况
AOF 重写期间继续 ****fsync: 在进行 RDB 持久化快照或 AOF 重写时Redis 将继续按照 appendfsync 配置进行 fsync 操作将 AOF 缓冲区中的数据同步到磁盘。保持 AOF 持久化的完整性: 即使在进行快照或 AOF 重写期间也不会延迟或暂停 AOF 文件的同步操作确保 AOF 文件的实时性和数据完整性。
no-appendfsync-on-rewrite 的值为 yes 时
AOF 重写期间暂停 ****fsync: 在进行 RDB 持久化或 AOF 重写时Redis 会暂停 fsync 操作。这意味着在持久化操作期间AOF 文件的数据不会实时同步到磁盘。降低磁盘 I/O 负载: 通过暂停 fsync可以减轻磁盘 I/O 负载减少系统压力和潜在的性能影响适合 I/O 密集型应用或磁盘性能有限的环境。 2.4 AOF持久化流程
1客户端的请求写命令会被append追加到 AOF 缓冲区内
2AOF缓冲区根据 AOF持久化策略[always,everysec,no]将操作sync 同步到磁盘的AOF文件中;
3AOF文件大小超过重写策略或手动重写时会对 AOF 文件rewrite 重写压缩AOF 文件容量
2.5 优点
备份机制更稳健丢失数据概率更低
可读的日志文本通过操作 AOF文件可以处理误操作
2.6 劣势
比起 RDB 占用更多的磁盘空间
恢复备份速度要慢
每次读写都同步的话有一定的性能压力
存在个别 Bug造成不能恢复
