【周阳-Redis】【05】Redis持久化：RDB+AOF

最新推荐文章于 2023-04-17 15:27:57 发布

lpruoyu

最新推荐文章于 2023-04-17 15:27:57 发布

阅读量214

点赞数

分类专栏：数据库文章标签： redis 缓存数据库

本文链接：https://blog.csdn.net/weixin_44018671/article/details/125004896

版权

数据库专栏收录该内容

47 篇文章 81 订阅

订阅专栏

持续学习&持续更新中…

守破离

【周阳-Redis】【05】Redis持久化：RDB+AOF

RDB（Redis DataBase）

SNAPSHOTTING（快照）

SNAPSHOTTING配置：

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed

save 900 1 # 若900秒内至少有1个key发生了改变，则满900秒时保存（持久化）一次
save 300 10 # 若300秒内至少有10个key发生了改变，则满300秒时保存一次
save 60 10000 # 若60秒内至少有10000个key发生了改变，则满60秒时保存一次

#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes

# The filename where to dump the DB
dbfilename dump.rdb

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

配置RDB快照的持久化策略

save <seconds> <changes>（Save the DB on disk:）

save 900 1 # 若900秒内至少有1个key发生了改变，则满900秒时保存（持久化）一次
save 300 10 # 若300秒内至少有10个key发生了改变，则满300秒时保存一次
save 60 10000 # 若60秒内至少有10000个key发生了改变，则满60秒时保存一次

如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以：
```
# save 10000 60
# ...
或者
save ""

动态所有停止RDB保存规则的方法：redis-cli config set save ""
```
stop-writes-on-bgsave-error：默认为yes，代表出错停写；如果配置成no，表示你不在乎数据不一致或者有其他的手段保证数据的正确性
rdbcompression：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

RDB是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是“行话”讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
PS：Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

如何触发RDB快照

配置文件中的快照配置

# Save the DB on disk: save <seconds> <changes>

save 900 1 # 若900秒内至少有1个key发生了改变，则满900秒时保存（持久化）一次
save 300 10 # 若300秒内至少有10个key发生了改变，则满300秒时保存一次
save 60 10000 # 若60秒内至少有10000个key发生了改变，则满60秒时保存一次

命令SAVE、BGSAVE

SAVE：save时只管保存，其它不管，全部阻塞
BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过LASTSAVE命令获取最后一次成功执行快照的时间

执行SHUTDOWN命令（停止Redis服务），会将内存数据写入dump.rdb
执行FLUSHALL命令，会产生dump.rdb文件，但里面是空的，无意义

RDB的优势与劣势

优势：1、适合大规模的数据恢复；2、对数据完整性和一致性要求不高。
劣势：1、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改；2、Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。

RDB小总结

在这里插入图片描述

AOF（Append Only File）

APPEND ONLY MODE

APPEND ONLY MODE配置：

############################## APPEND ONLY MODE ###############################

# AOF and RDB persistence can be enabled at the same time without problems.
# If the AOF is enabled on startup Redis will load the AOF, that is the file
# with the better durability guarantees.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no # 是否开启AOF持久化机制：no/yes

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.aof"

# Redis supports three different modes:
#
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
#
# The default is "everysec", as that's usually the right compromise between
# speed and data safety. It's up to you to understand if you can relax this to
# "no" that will let the operating system flush the output buffer when
# it wants, for better performances (but if you can live with the idea of
# some data loss consider the default persistence mode that's snapshotting),
# or on the contrary, use "always" that's very slow but a bit safer than
# everysec.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

# "no" that is the safest pick from the point of view of durability.

no-appendfsync-on-rewrite no

# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

auto-aof-rewrite-percentage 100 # 比上次AOF文件大小多100%（一倍）
auto-aof-rewrite-min-size 64mb

appendfsync：

always：每修改同步，同步持久化 每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好
everysec：每秒同步，出厂默认推荐，异步操作，每秒记录   如果一秒内宕机，有数据丢失
no：不同步

no-appendfsync-on-rewrite：重写时是否可以运用appendfsync，用默认no即可，保证数据安全性。
auto-aof-rewrite-min-size、auto-aof-rewrite-percentage：设置重写的基准值

AOF是什么

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)
只许追加文件但不可以改写文件
redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

AOF启动和恢复

正常恢复
1. 修改默认的appendonly no，改为yes
2. 将有数据的aof文件复制一份保存到对应目录（config get dir）
3. 重启redis让其重新加载
异常恢复
1. 修改默认的appendonly no，改为yes
2. 备份被写坏的AOF文件
3. redis-check-aof --fix进行修复
4. 重启redis让其重新加载

rewrite

AOF采用文件追加方式，因此文件会越来越大
为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令BGREWRITEAOF
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条的set语句。
重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
rewrite触发时机：Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

AOF小总结

相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
AOF每秒同步策略效率较好

总结

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。

同时开启RDB和AOF两种持久化方式

在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据
因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
那要不要只使用AOF呢？作者建议不要
因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

性能建议：

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
 
如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。
代价一是带来了持续的IO，
代价二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值。
 
如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。
能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构。

注意

Redis最起码也应该有一个主备集群
aof、rdb文件的修复

参考

尚硅谷-周阳: 尚硅谷超经典Redis教程.

本文完，感谢您的关注支持！

lpruoyu

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
【周阳-Redis】【05】Redis持久化：RDB+AOF

持续学习&持续更新中…守破离【周阳-Redis】【05】Redis持久化：RDB+AOFRDB（Redis DataBase）SNAPSHOTTING（快照）RDB是什么如何触发RDB快照RDB的优势与劣势RDB小总结AOF（Append Only File）APPEND ONLY MODEAOF是什么AOF启动和恢复rewriteAOF小总结总结注意参考RDB（Redis DataBase）SNAPSHOTTING（快照）SNAPSHOTTING配置：#############.
复制链接

扫一扫

专栏目录