一天入门redis-RDB、AOF

RDB

是什么？

每隔一段时间将内存中的数据集快照写入硬盘中(二进制形式)。如果需要恢复，则在将其读到内存中。

大概是怎么做的？

redis会fork一个进程来持久化，先创建临时文件，等写入工作完成后，替换掉上次的快照文件(dump.rdb文件，位于src目录下)。该过程中redis不执行任何IO操作，以确保较好的性能。

什么是Fork？

拷贝当前的进程，保持变量、环境变量、程序计算器不变，但是作为远进程的子进程。

存在问题

最后一次持久化后的数据可能会丢失。
恢复过程中redis停止工作，恢复时间比较长

使用场景

对于数据恢复的完整不是很敏感的条件下

如何配置快照文件？(自定义或者默认目录下)

sava 多长时间执行一次 如果超过多少次改变才执行
根据项目具体需求进行配置。如果需要备份当前版本的数据，可以冷拷贝，也就是执行指令（最好通过定时任务实现）

cp dump.rdb dump_new.rdb

如何手动触发备份？

指令：save和bgsave
区别：save会阻塞全部，而不管其他部分，bgsave的话会在后台操作，同时响应客户端请求。

如何恢复数据

替换dump.rdb后重启就行

AOF

是什么？

AOF 则以协议文本的方式，将所有对数据库进行过写入的命令（及其参数）记录到 AOF 文件（appendonly.aof），以此达到记录数据库状态的目的.重启之后会读取该文件(重启时将所有记录的写操作指令执行一遍)

如何做

• 重写机制：当追加后的文件越来越大时，超过所设定AOF文件的最大容量，就会启动内容压缩，只保留可以恢复数据的最小指令集，对应命令 bgrewriteaof;
• 触发机制：相似的，redis会fork出一条新进程来重写文件，先写到临时文件再替换掉原文件，将库中的数据全部记录为set语句。（Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发，但并发量大一点的项目都会配置在4 5G以上）

使用场景

与RDB配合使用，开启后如果出现问题只会丢失一秒左右的数据。

为什么不只使用AOF？

redis默认重启时会会载入aof文件，并且往往AOF的数据比RDB更新（RDB中备份的数据不实时），但是RDB更适合用于备份数据库，并且AOF有丢失数据的可能性，两个一起开启更安全。

如何配置

如果当前src下有rdb的备份文件的话，需要先运行 rm -f dump.rdb 指令删除，再开启服务器。
连接客户端，执行指令：

[root@localhost src]# ./redis-cli -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set a1 v1
OK
127.0.0.1:6379> set a2 v2
OK
127.0.0.1:6379> exit

发现文件下已经多出了appendonly.aof，使用cat指令进行查看。

*2
$6
SELECT
$1
0
*3
$3
set
$2
a1
$2
v1
*3
$3
set
$2
a2
$2
v2

再使用vim编辑，随机加入一些字符。
重启服务器，发现连接失败！

[root@localhost src]# ./redis-cli -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused
Could not connect to Redis at 127.0.0.1:6379: Connection refused

使用修复指令

./redis-check-aof --fix appendonly.aof 
[root@localhost src]# ./redis-check-aof --fix appendonly.aof 
0x              17: Expected prefix '*', got: 'd'
AOF analyzed: size=105, ok_up_to=23, diff=82
This will shrink the AOF from 105 bytes, with 82 bytes, to 23 bytes
Continue? [y/N]: y
Successfully truncated AOF

再次连接，发现已经正常，查看appendonly.aof ，发现有语法错误的地方直接被删除了！

什么情况下两种缓存都不需要使用？

只做缓存，也就是不需要任何持久化的时候

优缺点对比

RDB 优点

• 适合大规模数据，重启比aof快
• 最大化性能，唯一的会影响的性能的只有持久化过程中创建子线程去执行其他工作，父线程不会有操作磁盘等操作。
• 适合容灾恢复，压缩成单一文件适合传输
• 对数据完整性一致性要求性不高
• 每隔一段时间就会自动备份

AOF优点

多种同步方式：
- appendfsync always：每次写操作就立刻进行追加，性能比较差但是数据完整性比较好
- appendfsync everysec：每一秒进行同步，宕机时可能会丢失数据，但是性能好，对于数据完整性要求不严格可以采用
- 从不同步
- 宕机时不用担心数据丢失问题，如果写一半可以使用自带的修复工具
- 自动重写，重写后的文件是最小化的
- log可理解化，你甚至可以直接改写aof的log而不用连接服务器，而且可以通过备份该文件来做一些不可逆的操作。

RDB 缺点：

• 可能会丢失自上一次快照后的所有修改
• fork时内存数据拷贝过程中2倍的膨胀性
• 数据集很大情况下，fork过程消耗很多时间，导致可能redis停止服务

AOF缺点：

• 相同的数据集AOF占用空间大于rdb，恢复速度也比rdb慢
• 使用appendfsync always性能比rdb慢
• 大量大读写情况下RDB也有更强大的可靠性

使用建议

RDB只做紧急备份的话：只在从机上开启，而且间隔时间较长，15到20分钟才备份一次
在开启AOF情况下，会带来持续的IO以及覆盖文件的阻塞，这时可以增大最大值。在主从模式下，主机可以不开启aof，但是如果主从机同时宕机的话，不能只执行简单的修复，而是应该对比主从的log文件进行修复，再重启，消耗时间比较长。