小编给大家分享一下Redis持久化方案的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
Redis支持RDB与AOF两种持久化机制，持久化可以避免因进程异常退出或down机导致的数据丢失问题，在下次重启时能利用之前的持久化文件实现数据恢复。
RDB持久化
RDB持久化即通过创建快照（压缩的二进制文件）的方式进行持久化，保存某个时间点的全量数据。RDB持久化是Redis默认的持久化方式。RDB持久化的触发包括手动触发与自动触发两种方式。
手动触发
save， 在命令行执行save命令，将以同步的方式创建rdb文件保存快照，会阻塞服务器的主进程，生产环境中不要用
bgsave, 在命令行执行bgsave命令，将通过fork一个子进程以异步的方式创建rdb文件保存快照，除了fork时有阻塞，子进程在创建rdb文件时，主进程可继续处理请求
自动触发
在redis.conf中配置 save m n 定时触发，如 save 900 1表示在900s内至少存在一次更新就触发
主从复制时，如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
执行debug reload命令重新加载Redis时
执行shutdown且没有开启AOF持久化
redis.conf中RDB持久化配置
# 只要满足下列条件之一，则会执行bgsave命令
save 900 1 # 在900s内存在至少一次写操作
save 300 10
save 60 10000
# 禁用RBD持久化，可在最后加 save ""# 当备份进程出错时主进程是否停止写入操作
stop-writes-on-bgsave-error yes
# 是否压缩rdb文件 推荐no 相对于硬盘成本cpu资源更贵
rdbcompression no
AOF持久化
AOF（Append-Only-File）持久化即记录所有变更数据库状态的指令，以append的形式追加保存到AOF文件中。在服务器下次启动时，就可以通过载入和执行AOF文件中保存的命令，来还原服务器关闭前的数据库状态。
redis.conf中AOF持久化配置如下
# 默认关闭AOF，若要开启将no改为yes
appendonly no# append文件的名字
appendfilename "appendonly.aof"# 每隔一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec# 当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。
auto-aof-rewrite-percentage 100# 当AOF文件大小大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb
AOF持久化的实现包括3个步骤:
命令追加：将命令追加到AOF缓冲区
文件写入：缓冲区内容写到AOF文件
文件保存：AOF文件保存到磁盘
其中后两步的频率通过appendfsync来配置，appendfsync的选项包括
always， 每执行一个命令就保存一次，安全性最高，最多只丢失一个命令的数据，但是性能也最低（频繁的磁盘IO）
everysec，每一秒保存一次，推荐使用，在安全性与性能之间折中，最多丢失一秒的数据
no， 依赖操作系统来执行（一般大概30s一次的样子），安全性最低，性能最高，丢失操作系统最后一次对AOF文件触发SAVE操作之后的数据
AOF通过保存命令来持久化，随着时间的推移，AOF文件会越来越大，Redis通过AOF文件重写来解决AOF文件不断增大的问题（可以减少文件的磁盘占有量，加快数据恢复的速度），原理如下：
调用fork，创建一个子进程
子进程读取当前数据库的状态来“重写”一个新的AOF文件（这里虽然叫“重写”，但实际并没有对旧文件进行任何读取，而是根据数据库的当前状态来形成指令）
主进程持续将新的变动同时写到AOF重写缓冲区与原来的AOF缓冲区中
主进程获取到子进程重写AOF完成的信号，调用信号处理函数将AOF重写缓冲区内容写入新的AOF文件中，并对新文件进行重命名，原子地覆盖原有AOF文件，完成新旧文件的替换
AOF的重写也分为手动触发与自动触发
手动触发： 直接调用bgrewriteaof命令
自动触发： 根据auto-aof-rewrite-min-size和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持久化方案的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！
