#yyds干货盘点# redis | 十五、redis之持久化rdb和aof(上篇)
公众号：雨中散步撒哈拉文章同步公众号，共同学习进步
个人网站： https://liudongdong.top
文章来源： https://liudongdong.top/archives/redisshi-wu-redis-zhi-chi-jiu-hua-rdb-he-aof-shang-pian-
本篇便于学习，使用windows进行测试，redis版本Redis 3.2.100 (00000000/0) 64 bit
aof持久在下一篇，本篇只做rdb演示！下篇aof演示传送门：https://liudongdong.top/archives/redisshi-liu-redis-zhi-chi-jiu-hua-rdb-he-aof-xia-pian-
一、redis为什么持久化？
1. 概述
redis是一个内存数据库，数据保存在内存中，但是我们都知道内存的数据变化是很快的，也容易发生丢失。幸好Redis还为我们提供了持久化的机制，分别是RDB(Redis DataBase)和AOF(Append Only File)。Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。 由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。
2、二者的区别
[*]RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
[*]AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
二、RDB持久化方式
1. rdb持久化流程
在指定的时间间隔内将内存中的数据库快照写入磁盘，恢复时将库按照文件读取到内存中
[*]Redis 会单独创建一个子进程来进行持久化
[*]会先将数据写入到一个临时文件中
[*]待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
在整个过程中，主进程不进行任何 IO，因此主进程 ( 服务进程 ) 的性能很高
通过 RDB 方式持久化数据，整个 redis 数据库将会只包含一个 dump.rdb( 默认文件名 ) 文件，对于灾难恢复等情况下而言十分方便如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式比 AOF 方式更为高效
2. rdb配置解读
配置定位到如下图
1. rdb触发条件
# 下面是保存操作的实例：
# 900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）
# 300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）
# 60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）
save 900 1
save 300 10
save 60 100002. 写入失败
#在默认情况下，如果RDB快照持久化操作被激活（至少一个条件被激活）并且持久化操作失败，Redis则会停止接受更新操作。
#这样会让用户了解到数据没有被正确的存储到磁盘上。否则没人会注意到这个问题，可能会造成灾难。
#如果后台存储（持久化）操作进程再次工作，Redis会自动允许更新操作。
#然而，如果你已经恰当的配置了对Redis服务器的监视和备份，你也许想关掉这项功能。
#如此一来即使后台保存操作出错,redis也仍然可以继续像平常一样工作。
stop-writes-on-bgsave-error yes 3. 是否开启压缩
#是否在导出.rdb数据库文件的时候采用LZF压缩字符串和对象？
#默认情况下总是设置成‘yes’， 他看起来是一把双刃剑。
#如果你想在存储的子进程中节省一些CPU就设置成'no'，
#但是这样如果你的kye/value是可压缩的，你的到处数据接就会很大。
rdbcompression yes 4. 是否开启检查
#从版本RDB版本5开始，一个CRC64的校验就被放在了文件末尾。
#这会让格式更加耐检测，但是当存储或者加载rbd文件的时候会有一个10%左右的性能下降，
#所以，为了达到性能的最大化，你可以关掉这个配置项。
#
#没有校验的RDB文件会有一个0校验位，来告诉加载代码跳过校验检查。
rdbchecksum yes5. 导出数据库名称
# 导出数据库的文件名称
dbfilename dump.rdb 6. 工作目录
# 工作目录
# 导出的数据库会被写入这个目录，文件名就是上面'dbfilename'配置项指定的文件名。
# 只增的文件也会在这个目录创建（这句话没看明白）
# 注意你一定要在这个配置一个工作目录，而不是文件名称。
dir ./
3. rdb持久化测试
测试结束，配置文件不要忘了回复！
1. 前置环境准备
为了不影响后续测试环境，先进行环境打扫！
[*]修改rdb触发条件
修改为30秒内至少有1个key值发生改变
[*]删除之前rdb持久化的文档
2. 启动服务和客户端
[*]启动服务，启动时，加上刚刚修改过的配置文件，Linux同理
redis-server.exe redis.windows.conf
[*]启动客户端
3. 客户端添加至少一个值
127.0.0.1:6379> set k1 v2
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379>4. 观察dump是否创建
5. 清空数据库测试
[*]删除之前rdb持久化的文档
[*]客户端执行flushall命令
[*]观察持久化文档是否创建
6. rdb持久化测试总结
RDB 触发条件
[*]满足 save 配置的规则时，生成 RDB 文件
[*]使用命令 FLUSHALL，生成 RDB 文件
[*]关闭 Redis 进程时，生成 RDB 文件
[*]使用命令 save 或 bgsave
[*]1 save 会导致 redis 同步阻塞 ( 可以保证数据一致性 )，基本被废弃
[*]2 bgsave 时，redis 会在后台异步执行快照操作，同时可以响应客户端请求，但是当内存不够时将使用虚拟内存，导致 redis 阻塞
4. rdb恢复测试
1. 进行制作模拟数据
127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> set rdb_test test
OK
127.0.0.1:6379> save
OK
127.0.0.1:6379>2. 关闭redis客户端和服务
避免不必要的干扰和模拟服务器重新启动场景，进行关闭redis服务。
3. 文件移动和删除
[*]备份好的dump文件进行移动到和配置文件同级文件下
配置文件中也有相关配置
4. 重启redis服务并查看之前数据
三、rdb优缺点
1. 优点
[*]RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
[*]RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。
[*]RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
[*]RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2. 缺点
[*]如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。
[*]每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。
https://blog.51cto.com/u_13501912/4836945
页:
[1]