15. Redis 持久化_Redis 学习教程

目前Redis持久化的方式有两种： RDB 和 AOF。

首先，我们应该明确持久化的数据有什么用，答案是：用于重启后的数据恢复。

Redis是一个内存数据库，无论是RDB还是AOF，都是其保证数据恢复的措施。所以Redis在利用RDB和AOF进行恢复的时候，都会读取RDB或AOF文件，重新加载到内存中。

RDB

RDB就是Snapshot快照存储，是默认的持久化方式。可理解为半持久化模式：即按照一定的策略周期性的将数据保存到磁盘。对应产生的数据文件为dump.rdb，快照的周期通过配置文件中的save参数来定义。下面是默认的快照设置：

dbfilename dump.rdb
# save <seconds> <changes>
save 900 1    #当有一条Keys数据被改变时，900秒刷新到Disk一次
save 300 10   #当有10条Keys数据被改变时，300秒刷新到Disk一次
save 60 10000 #当有10000条Keys数据被改变时，60秒刷新到Disk一次

Redis的RDB文件不会坏掉，因为其写操作是在一个新进程中进行的。当生成一个新的RDB文件时，Redis生成的子进程会先将数据写到一个临时文件中，然后通过原子性rename系统调用将临时文件重命名为RDB文件。这样在任何时候出现故障，Redis的RDB文件都总是可用的。同时，Redis的RDB文件也是Redis主从同步内部实现中的一环。

第一次Slave向Master同步的实现是： Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。

第二次以及以后的同步实现是： Master将变量的快照直接实时依次发送给各个Slave。但不管什么原因导致Slave和Master断开重连都会重复以上两个步骤的过程。

Redis的主从复制是建立在内存快照的持久化基础上的，只要有Slave就一定会有内存快照发生。可以很明显的看到，RDB有它的不足，就是一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的。

从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。

AOF（Append-only file）方式

AOF(Append-Only File)比RDB方式有更好的持久化性。

在使用AOF持久化方式时，Redis会将每一个收到的写命令都通过Write函数追加到文件中，类似于MySQL的binlog。
当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

在Redis重启时会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中,所以说，载入的速度相较RDB会慢一些

默认情况下,Redis没有开启AOF方式的持久化,可以在redis.conf中通过appendonly参数开启:

 appendonly yes         #启用aof持久化方式
 # appendfsync always   #每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
 appendfsync everysec     #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
 # appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。

AOF文件和 RDB文件的保存文件夹位置相同,都是通过dir参数设置的,默认的文件名是appendonly.aof,可以通过appendfilename参数修改
```
 appendfilename appendonly.aof
```
AOF的完全持久化方式同时也带来了另一个问题，持久化文件会变得越来越大。

比如: 我们调用INCR test 命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的。因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。

为了压缩AOF的持久化文件，Redis提供了bgrewriteaof命令。收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，以此来实现控制AOF文件的增长。

配置Redis自动重写AOF文件的参数
```
 no-appendfsync-on-rewrite yes   #在AOF重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成`DISK IO`上的冲突。
 auto-aof-rewrite-percentage 100 #当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
 auto-aof-rewrite-min-size 64mb #当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
```

到底选择什么呢？

下面是来自官方的建议：

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

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

很多用户仅使用了AOF，但是我们建议，既然RDB可以时不时的给数据做个完整的快照，并且提供更快的重启，所以建议也使用RDB。

因此，我们希望可以在未来（长远计划）统一AOF和RDB成一种持久化模式。在数据恢复方面：RDB的启动时间会更短，原因有两个：

一是RDB文件中每一条数据只有一条记录，不会像AOF日志那样可能有一条数据的多次操作记录。所以每条数据只需要写一次就行了。

另一个原因是RDB文件的存储格式和Redis数据在内存中的编码格式是一致的，不需要再进行数据编码工作，所以在CPU消耗上要远小于AOF日志的加载。

既然持久化的数据的作用是用于重启后的数据恢复，那么我们有必要进行一次这样的灾难恢复模拟了。

如果数据要做持久化又想保证稳定性，则建议留空一半的物理内存。因为在进行快照的时候，fork出来进行dump操作的子进程会占用与父进程一样的内存，真正的copy-on-write，对性能的影响和内存的耗用都是比较大的。

目前，通常的设计思路是利用Replication机制来弥补aof、snapshot性能上的不足，达到了数据可持久化。

即Master上Snapshot和AOF都不做，来保证Master的读写性能，而Slave上则同时开启Snapshot和AOF来进行持久化，保证数据的安全性。

首先，修改Master上的如下配置：

$ sudo vim /redis/etc/redis.conf
#save 900 1 #禁用Snapshot
#save 300 10
#save 60 10000
appendonly no #禁用(注释)AOF

接着，修改Slave上的如下配置：

$ sudo vim /redis/etc/redis.conf
save 900 1 #启用Snapshot
save 300 10
save 60 10000
appendonly yes #启用AOF
appendfilename appendonly.aof #AOF文件的名称
# appendfsync always
appendfsync everysec #每秒钟强制写入磁盘一次
# appendfsync no  
no-appendfsync-on-rewrite yes   #在日志重写时，不进行命令追加操作
auto-aof-rewrite-percentage 100 #自动启动新的日志重写过程
auto-aof-rewrite-min-size 64mb  #启动新的日志重写过程的最小值

分别启动Master与Slave

$ redis-server /etc/redis/redis.conf

启动完成后在Master中确认未启动Snapshot参数

redis 127.0.0.1:6379> CONFIG GET save
1) "save"
2) ""

然后通过以下脚本在Master中生成25万条数据：

[email protected]:$ cat redis-cli-generate.temp.sh

#!/bin/bash
REDISCLI="redis-cli -a slavepass -n 1 SET"
ID=1
while(($ID<50001))
do
  INSTANCE_NAME="i-2-$ID-VM"
  UUID=`cat /proc/sys/kernel/random/uuid`
  PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`\
  CREATED=`date "+%Y-%m-%d %H:%M:%S"`
  $REDISCLI vm_instance:$ID:instance_name "$INSTANCE_NAME"
  $REDISCLI vm_instance:$ID:uuid "$UUID"
  $REDISCLI vm_instance:$ID:private_ip_address "$PRIVATE_IP_ADDRESS"
  $REDISCLI vm_instance:$ID:created "$CREATED"
  $REDISCLI vm_instance:$INSTANCE_NAME:id "$ID"
  ID=$(($ID+1))
done

[email protected]:$ ./redis-cli-generate.temp.sh

在数据的生成过程中，可以很清楚的看到Master上仅在第一次做Slave同步时创建了dump.rdb文件，之后就通过增量传输命令的方式给Slave了。dump.rdb文件没有再增大。

[email protected]:/opt/redis/data/6379$ ls -lh
total 4.0K
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb

下一节：Redis 性能测试是通过同时执行多个命令实现的。