Redis持久化的方法是什么

本文主要讲解“Redis持久化的方法是什么”，感兴趣的朋友不妨看看。本文介绍的方法简单、快速、实用。让边肖带你学习“Redis坚持的方法是什么？”！

RDB持久化雷迪斯支持RDB和AOF的持久性机制。持久化可以避免异常进程退出或机器宕机导致的数据丢失问题，并且可以利用之前的持久化文件在下次重启时实现数据恢复。

RDB持久化是通过创建快照(压缩的二进制文件)来持久化，并在某个时间点保存全部数据。RDB持久性是Redis默认的持久性方法。RDB持久性的触发包括手动触发和自动触发。

手动触发

保存，在

在命令行上执行保存。

命令，rdb文件将以同步方式创建以保存快照，这将阻止服务器的主进程，不应在生产环境中使用。

Bgsave，在命令行执行bgsave命令，通过fork的一个子进程，创建rdb文件以异步方式保存快照。除了fork期间有阻塞，当子进程创建rdb文件时，主进程可以继续处理请求。

自动触发

在redis.conf中配置了Save m n定时触发，例如，save 900 1表示在900s内至少有一次更新时触发。

在主从复制中，如果从节点执行完全复制操作，主节点会自动执行bgsave以生成RDB文件并将其发送给从节点。

执行debug reload命令重新加载Redis。

执行关闭且AOF持久性未打开。

redis.conf中的RDB持久性配置

#只要满足以下条件之一，就会执行bgsave命令。

Save9001#在900秒内至少有一次写操作。

save30010

储蓄6010000

#禁用RBD持久性，并在末尾添加保存' '。

#当备份进程出错时，主进程是否停止写入？

bgsave上停止写入-错误是

#压缩rdb文件推荐no比硬盘更贵耗费cpu资源。

AOF持久化区

AOF(Append-Only-File)持久化就是记录所有改变数据库状态的指令，并以追加的形式追加保存到AOF文件中。当服务器下次启动时，它可以通过加载和执行保存在AOF文件中的命令来恢复服务器关闭前的数据库状态。

redis.conf中的AOF持久性配置如下。

#默认情况下，AOF已关闭，如果已打开，请将“否”更改为“是”。

appendonlyno

#追加文件的名称。

appendfilename'appendonly.aof '

#每秒将缓冲区的内容写入文件。默认写入模式已启用。

appendfsynceverysec

#当AOF文件大小的增长率大于配置项时，将自动开始重写(这里指的是超过原始大小的100%)。

自动重写百分比100

#当AOF文件大于配置项时，自动打开重写。

持久性的自动重写最小大小64工商管理硕士的实现包括三个步骤：

追加：将命令追加到AOF缓冲区。

写：缓冲区的内容被写入AOF文件。

保存文件：将AOF文件保存到磁盘。

最后两个步骤的频率是通过appendfsync配置的，appendfsync的选项包括：

总是每执行一个命令保存一次，安全性最高，最多只丢失一个命令的数据，但性能最低(磁盘IO频繁)。

建议每秒保存一次。这是安全性和性能之间的折衷，最多会丢失一秒钟的数据。

不，它取决于执行它的操作系统(通常每30s执行一次)，它具有最低的安全性和最高的性能，并且在上次操作系统触发对AOF文件的SAVE操作后丢失数据。

通过保存命令来保持AOF。随着时间的推移，AOF的档案会越来越大。Redis通过重写AOF文件解决了增加AOF文件的问题(可以减少文件的磁盘占用，加快数据恢复速度)。原理如下：

调用fork创建一个子进程。

一个子进程读取数据库的当前状态来“重写”一个新的AOF文件(虽然这里称之为“重写”，但它实际上并不读取任何旧文件，而是根据数据库的当前状态形成指令)。

主进程同时不断向AOF重写缓冲区和原始AOF缓冲区写入新的更改。

主进程获得子进程重写AOF的信号，调用信号处理函数将AOF重写缓冲区的内容写入新的AOF文件，重命名新文件，原子性地重写原来的AOF文件，完成新旧文件的替换。

AOF的重写也分为手动触发与自动触发

手动触发：直接调用bgrewriteaof命令。

自动触发：根据auto-aof-重写-min-si。

ze和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小（aof_current_size）和上一次重写后AOF文件大小（aof_base_size）的比值。自动触发时机为 aof_current_size > auto-aof-rewrite-min-size &&（aof_current_size - aof_base_size）/aof_base_size> = auto-aof-rewrite-percentage

RDB vs AOF

RDB与AOF两种方式各有优缺点。

RDB的优点：与AOF相比，RDB文件相对较小，恢复数据比较快（原因见数据恢复部分）
RDB的缺点：服务器宕机，RBD方式会丢失掉上一次RDB持久化后的数据；使用bgsave fork子进程时会耗费内存。
AOF的优点： AOF只是追加文件，对服务器性能影响较小，速度比RDB快，消耗内存也少，同时可读性高。
AOF的缺点：生成的文件相对较大，即使通过AOF重写，仍然会比较大；恢复数据的速度比RDB慢。
数据库的恢复

服务器启动时，如果没有开启AOF持久化功能，则会自动载入RDB文件，期间会阻塞主进程。如果开启了AOF持久化功能，服务器则会优先使用AOF文件来还原数据库状态，因为AOF文件的更新频率通常比RDB文件的更新频率高，保存的数据更完整。

redis数据库恢复的处理流程如下，

在数据恢复方面，RDB的启动时间会更短，原因有两个：

RDB 文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了，文件相对较小。

RDB 文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。

但是在进行RDB持久化时，fork出来进行dump操作的子进程会占用与父进程一样的内存，采用的copy-on-write机制，对性能的影响和内存的消耗都是比较大的。比如16G内存，Redis已经使用了10G，这时save的话会再生成10G，变成20G，大于系统的16G。这时候会发生交换，要是虚拟内存不够则会崩溃，导致数据丢失。所以在用redis的时候一定对系统内存做好容量规划。

RDB、AOF混合持久化

Redis从4.0版开始支持RDB与AOF的混合持久化方案。首先由RDB定期完成内存快照的备份，然后再由AOF完成两次RDB之间的数据备份，由这两部分共同构成持久化文件。该方案的优点是充分利用了RDB加载快、备份文件小及AOF尽可能不丢数据的特性。缺点是兼容性差，一旦开启了混合持久化，在4.0之前的版本都不识别该持久化文件，同时由于前部分是RDB格式，阅读性较低。

开启混合持久化

aof-use-rdb-preamble yes

数据恢复加载过程就是先按照RDB进行加载，然后把AOF命令追加写入。

持久化方案的建议
如果Redis只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。
如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么可以仅使用RDB。
通常的设计思路是利用主从复制机制来弥补持久化时性能上的影响。即Master上RDB、AOF都不做，保证Master的读写性能，而Slave上则同时开启RDB和AOF（或4.0以上版本的混合持久化方式）来进行持久化，保证数据的安全性。

到此，相信大家对“Redis持久化的方法是什么”有了更深的了解，不妨来实际操作一番吧！这里是网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！