Redis持久化机制

Redis数据持久化

Redis做为一个内存数据库，数据是之内存为载体存储的，即断电即失（一旦Redis服务器进程退出，服务器中的数据也会消失）。为了解决这个问题，Redis提供了持久化机制，也就是把内存中的数据保存到磁盘当中，避免数据意外丢失

Redis提供了两种持久化方案：RDB持久化和AOF持久化，一个是快照的方式，一个是相似日志追加、历史记录的方式

1、RDB（Redis DataBase）

RDB是快照持久化，即经过快照SnapShot的方式，在指定的时间间隔内将内存中的数据集快照写入磁盘。在建立快照以后，用户能够备份该快照，能够将快照复制到其余服务器以建立相同数据的服务器副本，或者在重启服务器后恢复数据。RDB是Redis默认的持久化方式

RDB持久化会生成rdb文件，该文件是一个压缩过的二进制文件，能够经过该文件还原快照时的数据库状态，即生成该rdb文件时的服务器数据。rdb文件默认为当前工做目录下的dump.rdb，能够根据配置文件redis.conf中SNAPSHOTTING部分的dbfilename和dir设置rdb的文件名和文件位置。默认其实能够不须要改动。只要dump.rdb文件在redis的启动目录下，redis启动的时候就会自动检查dump.rdb恢复数据。

# 设置 dump 的文件名
dbfilename dump.rdb

# 工做目录
# 例如上面的 dbfilename 只指定了文件名，
# 可是它会写入到这个目录下。这个配置项必定是个目录，而不能是文件名。
dir ./

获取redis安装目录

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin" #若是在这个目录下存在dump.rdb文件，启动redis就会自动恢复数据

一、快照触发时机：

• 执行save和bgsave命令
• 配置文件中save <seconds> <changes>规则，自动间隔性执行bgsave命令，以下图

表示在seconds秒内，至少有changes次变化，就会自动触发gbsave命令

• 主从复制时，从库全量复制同步主库数据，主库会执行bgsave
• 执行flushall命令清空服务器数据
• 执行shutdown命令关闭Redis时，默认会执行save命令（能够手动shutdown nosave就不执行save命令）

二、save和bgsave命令：

执行save和bgsave命令，能够手动触发快照，生成rdb文件，二者的区别以下

使用save命令会阻塞Redis服务器进程，服务器进程在rdb文件建立完成以前是不能处理任何的命令请求

127.0.0.1:6379> save
OK
复制代码

而使用bgsave命令不一样的是，bgsave命令会fork一个子进程，而后该子进程会负责建立rdb文件，而服务器进程会继续处理命令请求。

fork()是由操做系统提供的函数，做用是建立当前进程的一个副本做为子进程

fork一个子进程，子进程会把数据集先写入临时文件，写入成功以后，再替换以前的rdb文件，用二进制压缩存储，这样能够保证rdb文件始终存储的是完整的持久化内容

【补充】

在生产环境中，一般咱们会将dump.rdb文件进行备份。

三、优缺点

优势：

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高

缺点：

• 在必定间隔时间作一次备份，若是redis意外宕机，会丢掉最后一次快照后的全部修改
• RDB使用fork()产生子进程进行数据的持久化，若是数据比较大的话可能就会花费点时间，形成Redis中止服务几毫秒。若是数据量很大且CPU性能不是很好的时候，中止服务的时间甚至会到1秒。

2、AOF（Append Only File）

AOF持久化会把被执行的写命令写到AOF文件的末尾，记录数据的变化。默认状况下，Redis是没有开启AOF持久化的，开启后，每执行一条更改Redis数据的命令，都会把该命令追加到AOF文件中，这就至关因而把redis执行过的全部指令记录下来（读操做不记录），有点相似历史记录，恢复数据时将这个文件所有执行一遍。这会下降Redis的性能，但大部分状况下这个影响是可以接受的，另外使用较快的硬盘能够提升AOF的性能。AOF保存的是appendonly.aof文件

在配置文件中redis.conf开启AOF和关于AOF的配置操做：

# appendonly参数开启AOF持久化，默认是no
appendonly no

# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同，都是经过dir参数设置的
dir ./

# 同步策略
# appendfsync always 表示每次写入都执行fsync，以保证数据同步到磁盘。
appendfsync everysec #表示每秒执行一次fsync，可能会致使丢失这1s数据。
# appendfsync no 表示不执行fsync，由操做系统保证数据同步到磁盘，速度最快。


# aof重写期间是否同步,默认no便可，保证数据安全
no-appendfsync-on-rewrite no

# 重写触发配置，设置重写的基准值
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof出错如何处理
aof-load-truncated yes

# RDB和AOF的混合持久化
aof-use-rdb-preamble yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

一、AOF的实现

AOF须要记录Redis的每一个写命令，步骤为：命令追加（append）、文件写入（write）和文件同步（sync）

命令追加(append)

开启AOF持久化功能后，服务器每执行一个写命令，都会把该命令以协议格式先追加到aof_buf缓存区的末尾，而不是直接写入文件，避免每次有命令都直接写入硬盘，减小硬盘IO次数

文件写入(write)和文件同步(sync)

对于什么时候把aof_buf缓冲区的内容写入保存在AOF文件中，Redis提供了多种策略

• appendfsync always：将aof_buf缓冲区的全部内容写入并同步到AOF文件，每一个写命令都同步写入磁盘
• appendfsync everysec：将aof_buf缓存区的内容写入AOF文件，每秒同步一次，该操做由一个线程专门负责
• appendfsync no：将aof_buf缓存区的内容写入AOF文件，何时同步由操做系统来决定

appendfsync选项的默认配置为everysec，即每秒执行一次同步

关于AOF的同步策略是涉及到操做系统的write函数和fsync函数的，在《Redis设计与实现》中是这样说明的

为了提升文件写入效率，在现代操做系统中，当用户调用 write函数，将一些数据写入文件时，操做系统一般会将数据暂存到一个内存缓冲区里，当缓冲区的空间被填满或超过了指定时限后，才真正将缓冲区的数据写入到磁盘里。

这样的操做虽然提升了效率，但也为数据写入带来了安全问题：若是计算机停机，内存缓冲区中的数据会丢失。为此，系统提供了fsync、fdatasync同步函数，能够强制操做系统马上将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。

从上面的介绍咱们知道，咱们写入的数据，操做系统并不必定会立刻同步到磁盘，因此Redis才提供了appendfsync的选项配置。

• 当该选项时为appendfsync always时，数据安全性是最高的，可是会对磁盘进行大量的写入，Redis处理命令的速度会受到磁盘性能的限制；
• appendfsync everysec选项则兼顾了数据安全和写入性能，以每秒一次的频率同步AOF文件，即使出现系统崩溃，最多只会丢失一秒内产生的数据；
• 若是是appendfsync no选项，Redis不会对AOF文件执行同步操做，而是有操做系统决定什么时候同步，不会对Redis的性能带来影响，但假如系统崩溃，可能会丢失不定数量的数据

二、AOF重写

随着时间的推移，Redis执行的写命令会愈来愈多，AOF文件也会愈来愈大，过大的AOF文件可能会对Redis服务器形成影响，若是使用AOF文件来进行数据还原所需时间也会越长。所以为避免出现此种状况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis 就会启动AOF 文件的内容压缩，只保留能够恢复数据的最小指令集。

文件重写能够自动触发也能够手动触发执行bgrewriteaof 命令

自动触发会根据auto-aof-rewrite-percentage和auto-aof-rewrite-min-size 64mb配置来自动执行bgrewriteaof命令

# 表示当AOF文件的体积大于64MB，且AOF文件的体积比上一次重写后的体积大了一倍（100%）时，会执行`bgrewriteaof`命令
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

手动触发执行bgrewriteaof，该命令的执行跟bgsave触发快照时相似的，都是先fork一个子进程作具体的工做

执行bgrewriteaof命令，重写的流程：

• 重写会有大量的写入操做，因此服务器进程会fork一个子进程来建立一个新的AOF文件
• 在重写期间，服务器进程继续处理命令请求，若是有写入的命令，追加到aof_buf的同时，还会追加到aof_rewrite_bufAOF重写缓冲区
• 当子进程完成重写以后，会给父进程一个信号，而后父进程会把AOF重写缓冲区的内容写进新的AOF临时文件中，再对新的AOF文件更名完成替换，这样能够保证新的AOF文件与当前数据库数据的一致性

三、AOF文件损坏

当AOF被损坏时候，启动redis，客户端链接时会出现Connection refused

这时可使用redis-check-aof --fix 进行修复

若是出现Successfully truncated AOF，就修复成功，重启能够恢复数据。链接客户端后能够get到数据

四、Redis4.0开始支持RDB和AOF的混合持久化

能够经过配置项 aof-use-rdb-preamble 开启，默认就是yes开启的

• 若是是redis进程挂掉，那么重启redis进程便可，直接基于AOF日志文件恢复数据
• 若是是redis进程所在机器挂掉，那么重启机器后，尝试重启redis进程，尝试直接基于AOF日志文件进行数据恢复，若是AOF文件破损，那么用redis-check-aof fix命令修复
• 若是没有AOF文件，会去加载RDB文件
• 若是redis当前最新的AOF和RDB文件出现了丢失/损坏，那么能够尝试基于该机器上当前的某个最新的RDB数据副本进行数据恢复

五、优缺点

优势：

• 数据更完整，安全性更高，秒级数据丢失（取决fsync策略，若是是everysec，最多丢失1秒的数据）
• AOF文件是一个只进行追加的日志文件，且写入操做是以Redis协议的格式保存的，内容是可读的，适合误删紧急恢复

缺点：

• 对于相同的数据集，AOF文件的体积要大于RDB文件，数据恢复也慢于rdb
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB。

参考：

一、https://juejin.im/post/684490... Redis持久化机制：RDB和AOF TurboSnail

---

谢谢您看完这篇技术文章

若是能对您有所帮助

那将是一件很美好的事情

保持好奇心的终身学习也是极棒的事

愿世界简单又多彩

转载请注明出处

​ ——纸飞机