【Redis学习笔记】持久化

Redis持久化分为2种：RDB（Redis DataBase）和AOF（Append Of File），可以根据具体情况使用其中的一种或者两种。

RDB（Redis DataBase）

概念

在指定的时间间隔内将内存中的数据写入到磁盘中（如10s中有2个key发生了变化）。

执行流程

在执行的时候会复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程，一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程

dump.rdb文件

生成的文件默认为dump.rdb，可在redis.conf中进行配置

触发策略

默认为900s至少1个key发生变化，300s至少10key发生变化，60s至少发生10000个key变化时，会触发持久化操作，可进行自定义配置

rdb的恢复

当重启redis时，只要在目录下存在dump.rdb文件会自动同步数据

优点

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间
• 恢复速度快

缺点

• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
• 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
• 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

AOF（Append Only File）

概念

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据

AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

可以在redis.conf中配置文件名称，默认为 appendonly.aof，默认是关闭的状态，
但是当和rdb同时开启时，redis优先采用aof恢复数据，因为aof的可靠性是高于rdb的

AOF同步频率设置

• appendfsync always
  始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
• appendfsync everysec
  每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
• appendfsync no
  redis不主动进行同步，把同步时机交给操作系统。

优点

• 备份机制更稳健，丢失数据概率更低。
• 可读的日志文本，通过操作AOF稳健，可以处理误操作。

缺点

• 比起RDB占用更多的磁盘空间。
• 恢复备份速度要慢。
• 每次读写都同步的话，有一定的性能压力。
• 存在个别Bug，造成恢复不能（文件内容发生未知变化）。

总结：

1. 如果对数据不敏感，可以选单独用RDB。
2. 不建议单独用 AOF，因为可能会出现Bug。
3. 如果只是做纯内存缓存，可以都不用