Redis持久化RDB (触发机制,流程解析,优点,缺点)
AOF (触发机制,aof常用配置总结,流程解析,重写机制,优点,缺点)
持久化的选择
持久化配置方案
| ||
为什么需要持久化: 持久化的功能:Redis是内存数据库,数据都是存储在内存中,进程退出数据就会永久丢失,所以需要定期将Redis中的数据从内存保存到硬盘。
Redis持久化分为RDB持久化和AOF持久化,前者是把当前数据保存到硬盘,后者则是把每次执行的写命令保存到硬盘。
| ||
RDB (默认RDB) |
| 把当前数据保存到硬盘 |
触发机制 | 手动触发分别对应 save 和 bgsave 命令 save 命令:阻塞当前 Redis 服务器,直到 RDB 过程完成为止,对于内存比较大的实例会造成长时间阻塞,线上环境不建议使用。
bgsave 命令:Redis 进程执行 fork 操作创建子进程,RDB 持久化过程由子进程负责,完成后自动结束。阻塞只发生在 fork 阶段,一般时间很短。
自动触发 RDB 的持久化机制 “save m n”。表示 m 秒内数据集存在 n 次修改时,自动触发 bgsave。 # 900s内至少达到一条写命令 save 900 1 这种通过服务器配置文件触发RDB的方式,与bgsave命令类似,达到触发条件时,会forks一个子进程进行数据同步,不过最好不要通过这方式来触发RDB持久化,因为设置触发的时间太短,则容易频繁写入rdb文件,影响服务器性能, 时间设置太长则会造成数据丢失。
( 把数据保存到硬盘的触发机制: 手动 save(阻塞) / bgsave(fork子进程) 自动 save 900 1 (不推荐,会影响服务器性能 => 频繁写入RDB文件) ) | |
流程解析 | 1)执行 bgsave 命令,Redis 父进程判断当前是否存在正在执行的子进程,如 RDB/AOF 子进程,如果存在 bgsave 命令直接返回。 2)父进程执行 fork 操作创建子进程,fork 操作过程中父进程会阻塞,通过 info stats 命令查看 latest_fork_usec 选项,可以获取最近一个 fork 操作的耗时,单位为微秒。 3)父进程 fork 完成后,bgsave 命令返回“Background saving started”信息并不再阻塞父进程,可以继续响应其他命令。 4)子进程创建 RDB 文件,根据父进程内存生成临时快照文件,完成后对原有文件进行原子替换。执行 lastsave 命令可以获取最后一次生成RDB 的时间,对应 info 统计的 rdb_last_save_time 选项。 5)进程发送信号给父进程表示完成,父进程更新统计信息,具体见 info Persistence 下的 rdb_* 相关选项。
( 1.判断当前是否存在执行的子进程 存在则bgsave直接返回 2.父进程fork创建子进程,fork操作过程中父进程可能会阻塞 3.bgsave返回 background saving started,不再阻塞父进程 ) | |
优点 | 1)RDB 保存了 Redis 在某个时间点上的数据,适合用于进行备份
2)父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程,然后这个子进程就会处理接下来的所有保存工作,父进程无须执行任何磁盘 I/O 操作。
3)RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
( 1.保存的是某个时间点的数据 2.父进程在保存RDB文件时唯一需要做的是fork一个子进程 3.恢复大数据的速度比AOF快 ) | |
缺点 | 1)RDB 方式数据没办法做到实时持久化/秒级持久化 (AOF可以解决 针对 RDB 不适合实时持久化的问题,Redis 提供了 AOF 持久化方式来解决 RDB存储某个时刻的快照不同,AOF持久化方式会记录客户端对服务器的每一次写操作命令到日志当中,并将这些写操作以Redis协议追加保存到以后缀为aof文件末尾)
2)如果数据量太大,forks的子进程也会发生阻塞,另外,forks子进程会耗费内存。
( 1.没办法做到实时,秒级别的持久化 2.fork子进程的时候,可能会阻塞 ) | |
AOF (如果开启了AOF,redis恢复的时候,会优先加载AOF,就会清空RDB,需要注意) | 触发机制 | AOF 重写过程可以手动触发和自动触发: ·手动触发:直接调用 bgrewriteaof 命令。
·自动触发:根据 auto-aof-rewrite-min-size和auto-aof-rewrite-percentage 参数确定自动触发时机。 ·auto-aof-rewrite-min-size:表示运行 AOF 重写时文件最小体积,默认为 64MB。 ·auto-aof-rewrite-percentage:代表当前 AOF 文件空间
示例: auto-aof-rewrite-percentage:100 auto-aof-rewrite-min-size:64mb 默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
AOF持久化的触发机制: 手动触发 bgrewriteof
自动触发 Auto-aof-rewrite-min-size Auto-aof-rewrite-percentage
|
Aof常用配置总结 | appendonly no:是否开启AOF appendfilename "appendonly.aof":AOF文件名 dir ./:RDB文件和AOF文件所在目录 appendfsync everysec:fsync持久化策略 no-appendfsync-on-rewrite no:AOF重写期间是否禁止fsync;如果开启该选项,可以减轻文件重写 时CPU和硬盘的负载(尤其是硬盘),但是可能会丢失AOF重写期间的数据;需要在负载和安全性之间进行平衡 auto-aof-rewrite-percentage 100:文件重写触发条件之一 auto-aof-rewrite-min-size 64mb:文件重写触发提交之一 aof-load-truncated yes:如果AOF文件结尾损坏,Redis启动时是否仍载入AOF文件 | |
流程如下 | 1)所有的写入命令会追加到 aof_buf(缓冲区)中。
2)AOF 缓冲区根据对应的策略向硬盘做同步操作。
3)随着 AOF 文件越来越大,需要定期对 AOF 文件进行重写,达到压缩的目的。
4)当 Redis 服务器重启时,如果开启了 AOF 文件,会优先加载aof进行数据恢复。 | |
重写机制说明 | AOF将客户端的每一个写操作都追加到aof文件末尾,随着命令不断写入 AOF,文件会越来越大,为了解决这个问题,Redis 引入 AOF 重写机制压缩文件体积。
AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程。
比如: 多条写命令可以合并为一个,如:lpush list a、lpush list b、lpush list c 可以转化为:lpush list a b c。 AOF 重写降低了文件占用空间,除此之外,另一个目的是:更小的 AOF 文件可以更快地被 Redis 加载。 | |
AOF的优点 | 1)AOF可以设置 完全不同步、每秒同步、每次操作同,默认是每秒同步。因为AOF是操作指令的追加,所以可以频繁的大量的同步。
2)AOF文件是一个值追加日志的文件,即使服务宕机为写入完整的命令,也可以通过redis-check-aof工具修复这些问题。
3)如果AOF文件过大,Redis会在后台自动地重写AOF文件。重写后会使AOF文件压缩到最小所需的指令集。
4)AOF文件因为是有序保存数据库的所有写入操作,所以即使如果不小心误操作数据库,也很容易找出错误指令,恢复到某个数据节点。
( 1.每秒同步 因为是追加指令的方式 2.aof文件过大 可以压缩 3.容易找出错误指令,因为文件是有序保存所有写操作 ) | |
AOF的缺点 | 1、相同数据量下,AOF的文件通常体积会比RDB大。因为AOF是存指令的,而RDB是所有指令的结果快照。但AOF在日志重写后会压缩一些空间。 2、在大量写入和载入的时候,AOF的效率会比RDB低。因为大量写入,AOF会执行更多的保存命令,载入的时候也需要大量的重执行命令来得到最后的结果。 RDB对此更有优势。
( 1.体积会比RDB大 因为AOF是指令,RDB是所有指令的结果快照 2.在大量写入和载入的时候,AOF的效率会比RDB低 ) | |
|
| AOF 和 RDB 文件都可以用于服务器重启时的数据恢复 |
持久化的选择 | 在实际生产环境中,根据数据量、应用对数据的安全要求、预算限制等不同情况,会有各种各样的持久化策略;此外,持久化的选择必须与Redis的主从策略一起考虑,因为主从复制与持久化同样具有数据备份的功能, 而且主机master和从机slave可以独立的选择持久化方案。 面分场景来讨论持久化策略的选择,下面的讨论也只是作为参考,实际方案可能更复杂更具多样性。 1)如果Redis中的数据完全丢弃也没有关系(如Redis完全用作DB层数据的cache),那么无论是单机, 还是主从架构,都可以不进行任何持久化。 2)在单机环境下(对于个人开发者,这种情况可能比较常见),如果可以接受十几分钟或更多的数据丢失,选择RDB对Redis的性能更加有利;如果只能接受秒级别的数据丢失,应该选择AOF。 3)但在多数情况下,我们都会配置主从环境,slave的存在既可以实现数据的热备,也可以进行读写分离分担Redis读请求,以及在master宕掉后继续提供服务。 在这种情况下的做法是: master:完全关闭持久化(包括RDB和AOF),这样可以让master的性能达到最好; slave:关闭RDB,开启AOF(如果对数据安全要求不高,开启RDB关闭AOF也可以),并定时对持久化文件进行备份(如备份到其他文件夹,并标记好备份的时间); 然后关闭AOF的自动重写,然后添加定时任务,在每天Redis闲时(如凌晨12点)调用bgrewriteaof。
为什么开启了主从复制,可以实现数据的热备份,还需要设置持久化呢?因为在一些特殊情况下,主从复制仍然不足以保证数据的安全,例如: master和slave进程同时停止:考虑这样一种场景,如果master和slave在同一个机房,则一次停电事故就可能导致master和slave机器同时关机,Redis进程停止;如果没有持久化,则面临的是数据的完全丢失。 master误重启:考虑这样一种场景,master服务因为故障宕掉了,如果系统中有自动拉起机制(即检测到服务停止后重启该服务)将master自动重启,由于没有持久化文件,那么master重启后数据是空的, slave同步数据也变成了空的;如果master和slave都没有持久化,同样会面临数据的完全丢失。需要注意的是,即便是使用了哨兵进行自动的主从切换,也有可能在哨兵轮询到master之前,便被自动拉起机制重启了。因此,应尽量避免“自动拉起机制”和“不做持久化”同时出现。 4)异地灾备:上述讨论的几种持久化策略,针对的都是一般的系统故障,如进程异常退出、宕机、断电等,这些故障不会损坏硬盘。但是对于一些可能导致硬盘损坏的灾难情况,如火灾地震,就需要进行异地灾备。 例如对于单机的情形,可以定时将RDB文件或重写后的AOF文件,通过scp拷贝到远程机器,如阿里云;对于主从的情形,可以定时在master上执行bgsave,然后将RDB文件拷贝到远程机器,或者在slave上执行bgrewriteaof重写AOF文件后,将AOF文件拷贝到远程机器上。一般来说,由于RDB文件文件小、恢复快,因此灾难恢复常用RDB文件;异地备份的频率根据数据安全性的需要及其它条件来确定,但最好不要低于一天一次。
持久化的选择: 需要与redis的主从一起考虑,持久化和主从复制同样具有数据备份的功能 1)完全丢失数据也没关系 2)单机环境下,可以接受10多分钟或者更多的数据丢失,选择RDB 3)配置了主从的环境
最好的做法是: 1)主服务器:完全关闭持久化,让其性能达到最好 2)从服务器:对数据安全要求高时,关闭RDB,开启AOF。 3)关闭AOF的自动重写,然后添加定时任务,每天闲时调用bgrewriteof
为什么开启了主从复制,可以实现数据的热备份,还需要设置持久化 因为在一些特殊情况下,主从复制仍然不足够保证数据的安全 1)因为停电事故,导致主从服务器同时停止 2)主服务器误重启,重启后如果没有持久化,就会清空数据,从服务器也会同步成空的了 3)异地灾备
定时将RDB和重写后的AOF文件,通过scp拷贝到远程机器
| |
持久化配置方案 | 1、企业级的持久化的配置策略 save 60 10000:如果你希望尽可能确保说,RDB最多丢1分钟的数据,那么尽量就是每隔1分钟都生成一个快照,低峰期,数据量很少,也没必要 10000->生成RDB,1000->RDB,这个根据你自己的应用和业务的数据量,你自己去决定 AOF一定要打开,fsync,everysec auto-aof-rewrite-percentage 100: 就是当前AOF大小膨胀到超过上次100%,上次的两倍 auto-aof-rewrite-min-size 64mb: 根据你的数据量来定,16mb,32mb 2、数据备份方案 RDB非常适合做冷备,每次生成之后,就不会再有修改了 数据备份方案 (1)写crontab定时调度脚本去做数据备份 (2)每小时都copy一份rdb的备份,到一个目录中去,仅仅保留最近48小时的备份 (3)每天都保留一份当日的rdb的备份,到一个目录中去,仅仅保留最近1个月的备份 (4)每次copy备份的时候,都把太旧的备份给删了 (5)每天晚上将当前服务器上所有的数据备份,发送一份到远程的云服务上去【crontab】
Crontab 定时做rdb备份,把太久的删除 |
2.redis持久化
最新推荐文章于 2022-09-01 11:01:45 发布