redis 持久化

redis持久化的方式有RDB，AOF 两种，默认方式是 rdb

Redis中数据存储模式有2种：cache-only,persistence;

一、rdb

RDB 功能最核心的是 rdbSave 和 rdbLoad 两个函数，前者用于生成 RDB 文件到磁盘， 而后者则用于将 RDB 文件中的数据重新载入到内存中：



SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数，但它们调用的方式各有不同：

SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。

BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。因为 rdbSave 在子进程被调用，所以 Redis 服务器在 BGSAVE 执行期间仍然可以继续处理客户端的请求

1. 概念

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

2. rdb持久化策略

自动方式

# Save the DB on disk:保存数据库到磁盘
#
#   save <秒> <更新>
#
#   如果指定的秒数和数据库写操作次数都满足了就将数据库保存。
#
#   下面是保存操作的实例：
#   900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）
#   300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）
#   60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）

save 900 1
save 300 10
save 60 10000

手动方式

阻塞方式: save

非阻塞方式的 bgsave

3. 工作目录

## redis.conf

#dbfilename：持久化数据存储在本地的文件
dbfilename dump.rdb
#dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下
dir ./

如果dir ./ ，意味着 启动命令所在的目录。

注意备份数据时，建议放到不同的机器上。

4. 工作原理

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

在执行fork的时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令 ），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork那一刻的内存数据。

5. rdb结构

我们用winHex打开dump.rdb文件

6. 压缩

# 是否在 dump .rdb 数据库的时候使用 LZF 压缩字符串
# 默认都设为 yes
# 如果你希望保存子进程节省点 cpu ，你就设置它为 no ，
# 不过这个数据集可能就会比较大
rdbcompression yes

# 是否校验rdb文件
rdbchecksum yes

7. 优缺点

RDB的优点是：

RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。

生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB的缺点是：：

- 数据可能丢失

- fork进程可能对加重内存的压力

8. 命令

==命令：==

- rdb 文件目录查询 config get dir

- 修复rdb文件 redis-check-rdb –fix

二、aof（Append-only file）

1. 概念

Redis AOF是类似于log的机制，将每一次写操作记入到磁盘文件中，当系统崩溃时，可以通过AOF来恢复数据。

AOF文件内容是字符串，非常容易阅读和解析

aof 默认是关闭的，如果要开启

appendonly yes

2. AOF持久化策略

自动方式

##指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec
appendfsync everysec

手动方式

阻塞方式: save

非阻塞方式的 bgsave

3. 工作目录

#dbfilename：持久化数据存储在本地的文件
dbfilename dump.rdb
#dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下
dir ./

4. 工作原理

Redis oaf机制包括了两件事，rewrite和AOF

==Redis AOF流程==

Redis Server启动，如果AOF机制打开那么初始化AOF状态，并且如果存在AOF文件，读取AOF文件。

随着Redis不断接受命令，每个写命令都被添加到AOF文件，AOF文件膨胀到需要rewrite时又或者接收到客户端的bgrewriteaof命令。

fork出一个子进程进行rewrite，而父进程继续接受命令，现在的写操作命令都会被额外添加到一个aof_rewrite_buf_blocks缓冲中。

当子进程rewrite结束后，父进程收到子进程退出信号，把aof_rewrite_buf_blocks的缓冲添加到rewrite后的文件中，然后切换AOF的文件fd。rewrite任务完成，继续第二个步骤。

redis并没有采用“基于原aof文件”来重写的方式，而是采取了类似snapshot的方式：基于copy-on-write，全量遍历内存中数据，然后逐个序列到aof文件中

5. 数据结构

普通文件描述

6. 压缩处理

aof 为了数据完整性，会记录每一次写操作，为了避免aof文件迅速膨胀，可以使用压缩方式处理

##在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no”
no-appendfsync-on-rewrite no

##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb”
auto-aof-rewrite-min-size 64mb

##相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。
##每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后
##触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。
auto-aof-rewrite-percentage 100

7. 优缺点

优点：

- 可以保持更高的数据完整性

缺点：

- AOF文件比RDB文件大，且恢复速度慢

- 瞬时io读写频繁

8. 命令

==命令：==

- rdb 文件目录查询 config get dir

- 修复rdb文件 redis-check-aof –fix

三、怎么选择rdb与aof

数据量大且对恢复速度有要求，对一致性要求不高的话，可以只使用RDB

只做缓存：不用开启任何的持久化方式

不建议只使用AOF 文件，RDB更适合备份数据库，AOF在不断变化不好备份，快速重启，而且不会又AOF可能潜在的BUG,留作万一的手段，同时存在时，优先使用AOF

redis replication 时，建议master，slaver 都开启aof

四、改进方法

为了克服rdb数据丢失的问题，使用 AOF 持久化

为了解决AOF瞬间IO问题，建议使用redis replication 主从复制

主从复制，请参考 redis 主从复制

五、性能

无持久化

snapshot

aof-always

aof-everysec

aof-no

五、参考文档

AOF

Redis核心解读–AOF与REWRITE机制