本文主要是介绍Redis-RDB、ADOF持久化，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

Redis-RDB、ADOF持久化

• 前言
• 一、RDB持久化
• • 0.简单介绍
  • 1.RDB备份流程
  • 2.触发模式
  • 3.优点
  • 4.缺点
• 二、AOF持久化
• • 0.简单介绍
  • 1.AOF备份流程
  • 2.文件同步触发策略
  • 3.重写触发（aof rewrite）
  • 4.优点
  • 5.缺点
• 三、混合持久化
• • 1.流程图
  • 2.配置方式
• 四、应用场景

前言

我们知道，Redis的数据是存储在内存中，断电即失，所以Redis大多用作缓存型数据库。但是Redis也是提供了RED持久化和AOF持久化两种方式，来把内存中的数据落盘到磁盘中。下面来主要介绍一下这两种方式。

一、RDB持久化

0.简单介绍

RDB持久化即通过创建快照（压缩的二进制文件）的方式进行持久化，保存某个时间点的全量数据。RDB持久化是Redis默认的持久化方式。RDB持久化的触发包括手动触发与自动触发两种方式。

1.RDB备份流程

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的（备份由子进程来完成），这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化的数据可能丢失。

关于fork

fork是linux系统创建子进程的API，子进程会把父进程的所有数据完全复制，但是这样会极大地消耗linux系统资源，所以Linux系统引入了“写时复制技术”。
写时复制技术：创建子进程并不会拷贝父进程的数据，而是共用。当父进程或子进程对源数据修改时，才会将修改的数据重新复制一份。

2.触发模式

1. 手动触发
   save和bgsave命令都可以手动触发RDB持久化。
   save命令会阻塞Redis服务，直到RDB持久化完成。
   bgsave命令不会阻塞，它是通过创建子进程来完成的RDB持久化操作。
2. 自动触发
   通过配置文件设置。
   设置save的相关配置，如sava m n，它表示在m秒内数据被修改过n次时，自动触发bgsave操作。

3.优点

1. RDB文件紧凑，体积小，网络传输快，适合全量复制；
2. 恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。

4.缺点

1. RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。
2. RDB文件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

二、AOF持久化

0.简单介绍

AOF（Append-Only-File）持久化即记录所有变更数据库状态的指令，以append的形式追加保存到AOF文件中。在服务器下次启动时，就可以通过载入和执行AOF文件中保存的命令，来还原服务器关闭前的数据库状态。

1.AOF备份流程

1. 客户端的请求写命令会被append追加到AOF缓冲区中
2. AOF缓冲区根据AOF持久化策略将操作sync同步到磁盘的AOF文件中
   

2.文件同步触发策略

AOF持久化流程中的文件同步有以下几个策略：

1. always：每次写入缓存区都要同步到AOF文件中，硬盘的操作比较慢，限制了Redis高并发，不建议配置。
2. no：每次写入缓存区后不进行同步，同步到AOF文件的操作由操作系统负责，每次同步AOF文件的周期不可控，而且增大了每次同步的硬盘的数据量。
3. eversec：每次写入缓存区后，由专门的线程每秒钟同步一次，做到了兼顾性能和数据安全。是建议的同步策略，也是默认的策略。

3.重写触发（aof rewrite）

aof 持久化策略会持久化所有修改命令；里面的很多命令其实可以合并或者删除；
aof rewrite 在 aof 的基础上，满足一定策略则 fork 进程，根据当前内存状态，转换成一系列
的 redis 命令，序列化成一个新的 aof 日志文件中，序列化完毕后再将操作期间发生的增量 aof 日
志追加到新的 aof 日志文件中国你，追加完毕后替换旧的 aof 日志文件；以此达到对 aof 日志瘦
身的目的；
注意：aof rewrite 开启的前提是开启 aof；

AOF重写是对原AOF文件大小的缩减，原理是通过计算所有的命令最终将命令缩为最简。
例如：
原文件：set k1 v1 set k2 v2 set k1 v2
重写后的文件：set k1 v2 set k2 v2

AOF持久化流程中的文件重写可以手动触发，也可以自动触发。重写过程在子进程中进行。

1. 手动触发：使用bgrewriteaof命令。
2. 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage配置确定自动触发的时机。
   auto-aof-rewrite-min-size表示运行AOF重写时文件大小的最小值，默认为64MB；
   auto-aof-rewrite-percentage表示当前AOF文件大小和上一次重写后AOF文件大小的比值的最小值，默认为100。只用前两者同时超过时才会自动触发文件重写。

4.优点

1. 支持秒级持久化，解决持久化实时性问题。
2. 兼容性好

5.缺点

1. 文件大
2. 恢复速度慢、对性能影响大。

三、混合持久化

从上面知道，rdb 文件小且加载快但丢失多，aof 文件大且加载慢但丢失少；混合持久化是吸取
rdb 和 aof 两者优点的一种持久化方案；
持久化期间修改的数据以 aof 的形式附加到文件的尾部；
混合持久化实际上是在 aof rewrite 基础上进行优化；所以需要先开启 aof rewrite；

1.流程图

2.配置方式

四、应用场景

1. 如果Redis只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。

2. 如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。

3. 如果你可以接受灾难带来的几分钟的数据丢失，那么可以仅使用RDB。

4. 通常的设计思路是利用主从复制机制来弥补持久化时性能上的影响。即Master上RDB、AOF都不做，保证Master的读写性能，而Slave上则同时开启RDB和AOF（或4.0以上版本的混合持久化方式）来进行持久化，保证数据的安全性。

这篇关于Redis-RDB、ADOF持久化的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！