Redis的单机持久化策略

说明

redis是一个内存数据库，每次服务器重启的时候内存中的数据都会丢失。所以Redis提供了两种持久化方式：RDB和AOF。RDB持久化方式是Redis将内存的数据以快照的方式存到磁盘中，生成一个以rdb为后缀的文件。该文件是一个二进制的字节码文件，也就是内存的状态。AOF持久化方式是Redis将所有的写操作以操作日志的方式记录到文件中。
Redis可以不开启持久化，也可以开启一个，也可以都开启。当都开启时会优先加载AOF文件，因为AOF文件保留的数据集比RDB更完整。

RDB

RDB简介

RDB是将内存的中的数据以快照的方式持久化到磁盘中，快照就是当前内存的数据集，其不关心数据是怎么来的，只关心当前内存中有什么样的数据。这种持久化方式是全量复制到磁盘，所以无法实时的进行持久化。Redis配置文件中可以设置持久化的频率，就是每间隔多长时间进行一次全量复制。比如每隔一小时就复制一次。每次进行RDB时，Redis会将本次生成的rdb文件替换上次的rdb文件，所以rdb文件需要另外写定时任务将rdb文件的副本保存到其他地方。

rdb的优点

• rdb是内存的快照，可以保存不同时间点内存快照，所以可以根据需求恢复到不同版本的数据集。
• redis加载rdb文件的成本非常低，可以很快的完成加载工作。
• rdb可以方便的进行网络传输，非常适用于数据同步和灾难恢复。
• rdb文件是由父进程创fork出的子进程生成的，父进程不需要做其他的IO操作，所以RDB可以最大化redis的性能

rdb的缺点

• 当redis意外宕机时会丢失还未持久化的数据
• 当数据集非常大的时候，fork子进程可能会需要毫秒级的停顿时间。

RDB工作方式

redis提供同步阻塞(save)和异步非阻塞(bgsave)的持久化。
当调用save命令的时候，redis会阻塞住，服务器无法处理任何客户端的任何请求，当数据量很大的时候并且服务器端还在继续对外提供服务时，要谨慎使用该命令。
除了阻塞方式，redis还提供异步非阻塞方式，即使用bgsave命令。无论使用同步方式还是异步方式，持久化操作都会需要一定的时间来生成dump.rdb文件，尤其是在大数据量的时候。所以从调用bgsave命令开始到bgsave命令完成的时间段内，很有可能会有客户端对数据进行新增，修改和删除。redis采用copy-on-write的方式保证了dump.rdb文件几乎是在bgsave开始时的数据状态。
copy-on-write写时复制技术是将fork出的子进程(这里是进行持久化生成dump.rdb的进程)与主进程共享同一块物理空间，各自保留该物理空间的指针副本。只有当父进程或者子进程发生更改行为时才为子进程分配相应的物理空间。
如图所示：
第一步：主线程fork出子线程时，子线程与主线程指向同一块数据。此时子线程读取内存中的数据，落入磁盘中。

第二步：如果在子线程工作的过程中，主线程收到修改key1的指令，主线程会复制key1到新的内存位置并修改。此时原来的key1的内存位置数据保留，方便子进程读取。

采用这种方式创建子进程，只是将内存地址复制出一份给子进程，非常的快速，保证了redis主线程的高效率(对于庞大的数据量，redis会有毫秒级的不能响应用户情况)，而且节省内存，保证数据的时刻性。

RDB的使用方式

在redis的配置文件中有SNAPSHOTTING快照的配置和介绍。
Redis支持通过配置时间和事件的方式来自动的执行bgsave。在配置文件中可以这样配置:

save 60 10000 的意思是在60秒之内如果事件达到10000则自动执行一次bgsave。
save 300 10 的意思是在300秒之内如果事件达到10则自动执行一次bgsave。
save 900 1 的意思是在900秒之内如果事件达到1则自动执行一次bgsave。
满足上面三个任意一个就执行bgsave。这样既保证了在高并发下短时间间隔内落入磁盘，也保证了在流量低峰时段减少持久化次数。
如果想关闭RDB则：
save “” 或者 将 save的配置删除。

当开启RDB时，如果redis不能正确的生成dump.rdb文件，redis默认会停止接受任何写操作。即
stop-writes-on-bgsave-error yes
将yes改为no 会关闭该配置。

redis默认开启字符串压缩，即：
rdbcompression yes
将yes改为no会关闭字符串压缩。

redis5后对rdb文件加入了CRC校验功能,该功能使rdb文件更有保证，但是会降低读写该文件的性能。
rdbchecksum yes
默认开启，该为no可将其关闭。

dbfilename dump.rdb 设置rdb的文件名。
dir ./ 设置rdb文件路径。

AOF

AOF简介

由于RDB是存储快照，无法完成实时持久化。Redis提供另一种持久化方式即AOF。AOF是以日志的方式记录每次服务器的写操作，当服务器重启的时候会重新执行这些命令来恢复原始数据。AOF文件存储的是写操作命令。比如set，与RDB文件明显不同的是，AOF文件人可以看懂。

AOF的工作方式

RDB备份文件：

AOF备份文件：


上图就是AOF日志文件。这里做一个简单说明: 以*号开头的代表要存储的是命令，*后面的数字代表命令由几个单词组成。以$开头的代表下面一行是单词，$后面的数字代表单词有几个字符。
上图中 *2 代表后面的命令由两个单词构成，即select 0; $5代表后面的单词有5个字符组成即select; $1代表后面的单词由一个字符构成即 0; 所以 第一条指令就是 select 0。客户端连上服务端后默认执行select 0 ， 使用0号库。
该文件并没有记录get指令。说明该文件只记录写操作，不记录读操作。
如果开启AOF，redis服务端启动时只会加载该文件，忽略rdb文件，因为该文件比rdb文件的数据要完整。
上面的AOF文件中记录了三条对key1的set指令操作，当加载该文件时会指令两条无用的指令。redis提供了优化aof文件的指令: bgrewriteaof, 该指令会把aof文件中过时的指令清除掉，从而减小aof文件的大小。

上图是执行该指令之后的aof文件内容。

AOF的优点

• aof比rdb具有更好的持久化策略。redis提供三种aof持久化策略: 每次写操作都进行持久化，每秒进行持久化和由操作系统自己决定何时持久化(根据系统缓存来决定，当缓冲区满了时会自动将指令写入磁盘)。
• AOF文件是一个日志追加文件，每次只需要在文件中追加新的操作指令。
• AOF文件可以进行优化重写，去掉过时的操作指令(如上图)。在重写的过程中，会先重建一个临时的AOF文件，旧的文件仍然在进行着追加操作，当新的文件创建完毕时，才将旧的切换到新的，并开始在新的文件中追加。
• 文件易读，当不小心执行flushall指令时，只要aof文件没有被重写，则可以人为的将该文件的flushall指令删除重新加载。

AOF的缺点

• 相对与rdb文件，AOF文件的体积通常要大于RDB文件的体积。
• 根据AOF的持久化策略不同，其速度可能会慢与RDB。当redis不主动执行策略时，其效率可以媲美rdb方式。

AOF的使用方式

在配置文件中有APPEND ONLY MODE模块对AOF的配置。

• appendonly yes 开启AOF。默认为no关闭。
• appendfilename “appendonly.aof” 设置AOF文件的名称
• appendfsync everysec 设置AOF持久化策略默认为 everysec，还可以为 always或者no
• no-appendfsync-no-rewrite no 当进行aof文件重写时，对新的写入操作不进行持久化，暂存在缓存中。yes与no相反。建议开启。
• auto-aof-rewirte-percentage 100 自动重写配置，设置为100代表AOF文件增长到上次文件的2倍时重写文件
• auto-aof-rewrite-min-size 64mb 自动重写配置，允许重写的最小文件大小，避免在文件很小的时候会频发的触发重写操作
• aof-load-truncated yes aof文件的尾部可能不是完整的，当此配置为yes时，在redis载入aof文件时，如果文件不完整会自动发布一个log给客户端，然后load。当为no时，则需要手动reids-check-aof才可以。

AOF与RDB混合方式

redis4.0版本之后提供了AOF与RDB混合模式。简单来说就是采用AOF方式时，执行rewrite时，将内存已RDB的方式写入到aof文件中，这样可以更快的完成rewrite操作，而且极大的减少了aof文件的大小。然后aof还是以追加指令的方式加入aof文件，直到再次rewrite。
aof-use-rdb-preamble yes 默认开启混合方式，改为no可以关闭该方式。

上图为开启混合模式后aof文件的内容,

执行完bgrewriteaof后的内容。