（十一）Redis数据库-Redis两种持久化方式：RDB与AOF

我的系统版本为CentOS7.5，redis版本5.0.4

RDB持久化

RDB可以在配置文件中配置持久化的策略，也可以通过SAVE命令进持久化。RDB是异步的持久化，无法实现实时持久化。执行持久化时会在安装目录生成一个dump.rdb的二进制文件来存储内存的快照。RDB持久化的方式处理效率较高。

#通过redis.conf配置文件配置，900秒内有一条数据变化或300秒内有10条数据变化或60秒内有1条数据变化。
save 900 1
save 300 10
save 60 10000

#也可通过执行save命令手动持久化。
save

持久化的二进制文件在服务启动时自动加载。

AOF持久化

AOF持久化的原理是将所有执行写入的命令都保存到appendonly.aof文件，打开该文件可以看到历史执行的写入命令，AOF方式有三种模式：1、实时持久化 2、每秒持久化 3、让系统决定。AOF可以实现实时的持久化，但是会严重影响性能，并且大量重复的写入命令会让AOF文件非常放大，如果文件过大需要定期重写AOF文件。

#通过redis.conf配置文件配置，
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

选项	含义
always	每个 Redis 命令都要同步写入硬盘。这样会严重降低 Redis 的性能
everysec	每秒执行一次同步，显式地将多个写命令同步到硬盘
no	让操作系统来决定应该何时进行同步

AOF重写

随着redis的运行会有大量的冗余的写入命令，例如先执行了set age 18 后来又执行了set age 19 ，那么前面的执行命令就是冗余无效的，运行时间越长无效的命令就会越多，AOF文件也会越大。重写时redis会创建一个子进程对AOF文件进行重写。

rewrite操作具体流程:
（1）redis fork一个子进程
（2）子进程基于当前内存中的数据，构建日志，开始往一个新的临时的AOF文件中写入日志
（3）redis主进程，接收到client新的写操作之后，在内存中写入日志，同时新的日志也继续写入旧的AOF文件
（4）子进程写完新的日志文件之后，redis主进程将内存中的新日志再次追加到新的AOF文件中
（5）用新的日志文件替换掉旧的日志文件

#手动重写
bgrewriteaof

#通过redis.conf配置文件配置自动重写
#根据上一次rewrite大小按照增加比例进行，例如上次rewrite后为1000MB，则到2000MB时再次rewrite
auto-aof-rewrite-percentage 100

#触发rewrite的最小aof文件体积，也就是如果没有达到触发体积也不会进行rewrite
auto-aof-rewrite-min-size 1024mb

如果redis在append数据到AOF文件时，机器宕机了，可能会导致AOF文件破损
用redis-check-aof --fix命令来修复破损的AOF文件

持久化数据恢复

（1）AOF持久化开启且存在AOF持久化文件时首先加载AOF文件

（2）AOF关闭或AOF持久化文件不存在时，加载RDB文件

（3）加载AOF/RDB文件成功后，redis启动成功

（4）AOF/RDB文件存在错误时，redis启动失败并打印错误日志

两个持久化的性能对比

因为AOF后两种持久化不能时间实时，所以讲AOF的模式设置为always对比RDB异步和AOF实时持久化性能的差异。
使用redis自带的性能测试工具，使用RDB异步持久化，默认参数情况（windows的电脑hyper-v虚拟机建了个centos的虚拟机，2GB内存）：

PING_INLINE: 51813.47 requests per second
PING_BULK: 47619.05 requests per second
SET: 49751.24 requests per second
GET: 49504.95 requests per second
INCR: 48309.18 requests per second
LPUSH: 50505.05 requests per second
RPUSH: 49504.95 requests per second
LPOP: 51546.39 requests per second
RPOP: 50505.05 requests per second
SADD: 46296.30 requests per second
HSET: 50761.42 requests per second
SPOP: 50251.26 requests per second
LPUSH (needed to benchmark LRANGE): 48543.69 requests per second
LRANGE_100 (first 100 elements): 35842.29 requests per second
LRANGE_300 (first 300 elements): 18726.59 requests per second
LRANGE_500 (first 450 elements): 14749.26 requests per second
LRANGE_600 (first 600 elements): 11961.72 requests per second
MSET (10 keys): 55248.62 requests per second

开启AOF实时持久化后的性能测试：

PING_INLINE: 54347.82 requests per second
PING_BULK: 51020.41 requests per second
SET: 5265.93 requests per second
GET: 50000.00 requests per second
INCR: 5141.39 requests per second
LPUSH: 5149.33 requests per second
RPUSH: 5271.48 requests per second
LPOP: 5500.55 requests per second
RPOP: 5488.47 requests per second
SADD: 51546.39 requests per second
HSET: 5197.51 requests per second
SPOP: 50000.00 requests per second
LPUSH (needed to benchmark LRANGE): 5527.92 requests per second
LRANGE_100 (first 100 elements): 36101.08 requests per second
LRANGE_300 (first 300 elements): 18832.39 requests per second
LRANGE_500 (first 450 elements): 14184.40 requests per second
LRANGE_600 (first 600 elements): 11904.76 requests per second
MSET (10 keys): 5120.33 requests per second

通过对比，开启AOF实时持久化后写入操作的性能降低了一个数量级。

？？？疑问待解？？？
在开启AOF实时持久化后SET降低了一个数量级，SADD和SPOP同样是写入操作，性能缺没有明显变化。通过tail -f /appendonly.aof可以看到sadd和spop命令都是会实时写入AOF文件的。