共计 3488 个字符，预计需要花费 9 分钟才能阅读完成。
这篇文章主要讲解了“redis 的持久化怎么理解”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“redis 的持久化怎么理解”吧！
redis 的持久化：
概念：将内存中的数据保存到磁盘，在机器宕机或重启时可以保证数据不丢失。
说明：建议 RDB 和 AOF 同时开启，若二者同时开启，则 redis 在启动时优先使用 aof 文件来恢复数据，若读取 aof 文件失败，则读取 rdb 文件来恢复数据。
RDB(Redis DataBase)
概念：
将内存中的数据进行快照并且存储到磁盘上，即在指定目录下生成一个 dump.rdb 文件。RDB 是 redis 默认的持久化方式。
redis 启动后可用通过读取 rdb 文件，将数据再次载入到内存中，一般情况下 1G 的 rdb 文件载入到内存的时间大概为 20~30 秒。
过程：把所有的数据都写到一个临时文件中，然后用这个临时文件替换掉之前的 rdb 文件。
触发机制：
手动触发：
save 命令：阻塞 Redis 当前的进程，直到 RDB 过程完成为止。若实例占用的内存比较大，则会造成 redis 服务长时间的不可用。(不建议使用)
bgsave 命令：redis 当前进程执行 fork 操作创建子进程，RDB 持久化过程由子进程负责，父进程继续接收并处理客户端发出的请求。阻塞只发生在 fork 阶段，一般时间很短。
注意：fork 一个进程时，子进程占用的内存空间与父进程相同。
自动触发：
达到配置的条件时，自动触发 bgsave 命令。
在执行 shutdown 命令后会自动触发 bgsave 命令。
配置文件 redis.conf：
# 设置触发快照的条件 (Will save the DB if both the given number of seconds and the given number of write operations against the DB occurred.)
# 格式：save seconds changes
save 900 1 # 900 秒内，如果有 1 个以上(包括 1 个) 的 key 被修改了，则触发快照。
save 300 10 # 300 秒内，如果有 10 个以上 (包括 10 个) 的 key 被修改了，则触发快照。
save 60 10000 # 60 秒内，如果有 10000 个以上 (包括 10000 个) 的 key 被修改了，则触发快照。
# RDB 默认会开启，关闭 RDB 方式的持久化
save
# 设置 rdb 文件的名称
dbfilename dump.rdb
# 设置 redis 的工作目录，即 rdb 文件、aof 文件所在的目录
# 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.
dir ./
# 设置 rdb 文件是否进行压缩，默认为 yes。注：压缩 rdb 文件可以减少磁盘空间的占用，但是需要消耗额外的 cpu。
rdbcompression yes
优点：适合大规模的数据恢复，且数据加载的速度比较快。
缺点：无法做到数据实时的(秒级) 持久化。故数据备份的完整性不高。
AOF(Append Only File)
概念：
将发送到 redis 服务端的每一条写操作都存储到磁盘上，即在指定目录下生成一个 appendonly.aof 文件，并且将每次的写操作追加到 aof 文件的末尾。
redis 启动后通过读取 aof 文件，将 aof 文件中的写操作依次再执行一遍，以此来达到数据恢复的效果。
过程：命令写入 (append) 到缓存区、将缓存区的数据同步到 aof 文件中 (sync)、重新 aof 文件(rewrite)
重写 aof 文件：
目的：去除数据的中间执行过程，保留最终数据的命令，可大大减小 aof 文件的大小，从而可以加快数据恢复的速度。
过程：redis 当前进程执行 fork 操作创建子进程(开销等同于 bgsave 过程)，子进程根据命令合并规则将内存中的数据写入到新的 AOF 文件中，最后用新的 aof 文件替换掉现有的 aof 文件。
触发机制：
手动触发：
BGREWRITEAOF
若 aof 文件格式异常，则需要修复 aof 文件：redis-check-aof –fix appendonly.aof
自动触发：
达到配置的条件时，自动触发更新 aof 文件 或 重新 aof 文件 的操作。
3) 配置文件 redis.conf：
# AOF 和 RDB 可以同时存在，AOF 方式的持久化拥有更好的数据完整性和一致性。
# 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.
# 开启 AOF (AOF 默认是关闭的 appendonly no)
appendonly yes
# 设置触发更新 aof 文件的条件
# appendfsync always # 同步持久化，即每次执行写操作后都会去更新 aof 文件。数据完整性好，但是性能较差。
appendfsync everysec # 每秒同步一次，是 AOP 默认触发更新日志的条件。
# appendfsync no # 不主动同步，由操作系统来决定什么时候同步(一般为 30s)，性能最好但是持久化得不到保障，故不推荐使用该配置。
# 设置触发重写 aof 文件的条件，多个条件是 与 的关系。
# redis 在重写 aof 文件后会将 aof 文件的大小记录下来(若没有重写过 aof 文件，则这个大小默认是 redis 启动时 aof 文件的大小)
auto-aof-rewrite-percentage 100 # 当前 aof 文件的大小 超过 上一次重写后记录的大小 的 100%。
auto-aof-rewrite-min-size 64mb # 当前 aof 文件大于等于 64mb。注一般不会设置的这么小，看情况设为 ngb 比较合理。
# 设置 aof 文件的名称
# appendfilename appendonly.aof
# 设置 redis 的工作目录，即 rdb 文件、aof 文件所在的目录
dir ./
优点：可以做到数据实时的(秒级) 持久化，故数据备份的完整性很高。
缺点：AOF 记录的内容多，文件会越来越大，数据恢复也会越来越慢，故 redis 在 AOF 中引入了重写 aof 文件的机制。
持久化给 redis 带来的开销：
概念：子进程在重写 RDB 文件和重写 AOF 文件时会消耗 cpu、内存、硬盘等资源。
cpu：子进程负责把进程内的数据分批写入文件，这个过程属于 CPU 密集操作，通常子进程对单核 CPU 利用率接近 90%。
内存：父进程 fork 子进程时，子进程默认占用的内存同父进程一样。我们可以修改 Linux 内存分配的配置，避免物理内存不足导致 fork 进程失败。
硬盘：往 rdb 文件或 aof 文件中写数据的过程中，磁盘 io 的压力比较大。
说明：开启 AOF 的 Redis 在高流量写入时，如果使用普通机械磁盘，写入吞吐一般在 100MB/ s 左右，这时 Redis 实例的瓶颈主要在 AOF 同步硬盘上。
注意：redis 实例不应该和其它对 cpu、内存、硬盘敏感的服务混部。
感谢各位的阅读，以上就是“redis 的持久化怎么理解”的内容了，经过本文的学习后，相信大家对 redis 的持久化怎么理解这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！
