redis的持久化怎么理解

这篇文章主要讲解了“redis的持久化怎么理解”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“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
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的持久化怎么理解这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是开发云，小编将为大家推送更多相关知识点的文章，欢迎关注！

相关推荐: Docker容器的自动化监控实现方法

这篇文章主要讲解了“Docker容器的自动化监控实现方法”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Docker容器的自动化监控实现方法”吧！ 近年来容器技术不断成熟并得到应用。Docker作为容器技术的一个…