Redis里面的aof和rdb

Redis里面的持久化：RDB和AOF

关于redis里面的持久化方案有两种：
RDB(Redis DataBase)
AOF(Append Only File)

关于Rdb
这是redis里面默认提供的一套持久化技术方案，专门用于保证内存中的数据被写入到磁盘里面去。主要配置是修改相应的redis.conf来实现

redis里面的这一行主要是用于将数据持久化在redis的dump.rdb文件里面，然后每一次开启redis的时候都会将里面的数据重新加载，进行数据恢复。（dump.rdb的存放位置由下边的dir来标识）

这一段配置主要是rdb的核心规则配置内容：
save <指定时间间隔> <执行指定次数更新操作> （默认是save 900 1）
举个例子来说：
save m n
也就是说m秒类如果进行了n次操作，就会将数据存储到dump.rdb文件中去。
rdb里面并不是单纯将数据直接存储起来，而是通过一种特定的lzf压缩方式来实现的：

这个配置开关最好打开（默认开启），否则会导致rdb文件过大，占用磁盘空间。

触发rdb存储机制的条件：
1.显示执行save指令（但是这是一种阻塞式指令）

2.执行flushall指令的时候，清空所有数据
3.执行shutdown指令
4.在指定时间间隔，操作次数达到save配置的数目

通常我们都会对rdb文件做相应的备份处理。

RDB的优缺点
优点：
1.对于一致性，数据完整性要求不高的情况下，这种类型的持久化处理会比较适合
2.适用于大规模的数据恢复

缺点：
1.需要开启一个额外的线程来进行数据存储，会占用内存空间（此时是两倍的内存空间）
2.数据的完整性和一致性不高，如果在最后一次备份的时候宕机了，就会导致部分数据丢失。

接下来我们来演示一段redis里面进行rdb数据恢复的过程
首先我们需要修改rdb的配置信息

  [root@idea-centos bin]# vim redis.conf

修改内容

    save 900 1
    save 120 5
    save 60 10000


[root@idea-centos bin]# ./redis-server redis.conf
[root@idea-centos bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> set key2 value2
OK
127.0.0.1:6379> set key3 value3
OK
127.0.0.1:6379> set key4 value4
OK
127.0.0.1:6379> set key5 value5
OK
127.0.0.1:6379> set key6 value6
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@idea-centos bin]# cp dump.rdb dump_bk.rdb
[root@idea-centos bin]# ./redis-server redis.conf
[root@idea-centos bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> FLUSHALL 
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@idea-centos bin]# cp dump_bk.rdb  dump.rdb
cp: overwrite `dump.rdb'? y
[root@idea-centos bin]# ./redis-server redis.conf
[root@idea-centos bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "key5"
2) "key1"
3) "key3"
4) "key4"
5) "key6"
6) "key2"

ps:一般情况下我们很少会用flushall指令和shutdown指令，这里只是为了模拟测试才使用的。

AOF方式持久化
为了弥补rdb的不足之处，数据的不一致性，aof出现了。它是采用日志的形式来将每一次写操作都进行记录，追加到相应的文件中去。Redis重启的时候会根据日志文件的内容从前到后执行一次。
首先我们需要开启appendonly选项

同时还需要指定文件的位置：

除此之外还有相应的aop日志更新条件可以查看：

AOF的快照处理方式：
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步

关于AOF的重写机制
上边在写rdb重写机制的时候有讲到过rdb文件压缩的原理是使用算法将二进制文件进行压缩，而对于AOF来说，aof是采用去除无效命令的方式来进行空间压缩的。
例如说同一个key进行了重复的插入，那么就只保留最后一次插入的数据。
AOF里面出发该机制的条件可以在conf文件里面进行配置：
触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。不过一般64m太小了。

重写的原理：
AOF会开启一条后台进程来读取内存中的数据，先写入到一个临时文件里面，然后替换旧有的aof文件。
AOF优缺点：
数据的完整性和一致性会更高
由于aof记录内容过多，文件会不断变大，数据恢复变慢。