Redis-持久化

by shihang.mai

凡是存储，都有快照/副本、日志

1. RDB

RDB(redis db)描述的是快照/副本

Linux存在父子进程，而且子进程可以看到父进程的数据。子进程和父进程变量之间互不影响。

redis RDB

例如在8:00时,触发RDB

1. redis的内存fork()出一个子进程如图,这时复制的只是指针，速度快

2. 当有请求修改key=a的值为w时,内核用了copy on write机制,在内存中重新在另外一个地址上有一个值w,然后key=a重新指向w（上图红色线）,这样做修改并不会影响子进程。这样做内存也用得少

3. 这样做达到了速度快，内存也用得少。也保证了redis的时点性

1.1 RDB弊端

1. 只有一个dump.rdb，即只有一个备份文件。

2. 时点之间的数据丢失。

1.2 RDB优点

1. 类似java的序列化，恢复的速度相对快

2. AOF

AOF(append-only file)描述的是日志

redis的写操作记录到文件中，有3个级别设置写文件的频率

• appendfsync always 每次操作都写
• appendfsync everysec 每秒写,期间所有的命令都会存储在 aof 缓存区
• appendfsync no 不做控制，任由操作系统决定什么时候刷新缓冲区

RDB和AOF同时开启的话，那么恢复时只会用AOF

在4.0前,写AOF文件,会合并命令(如set key1 a和set key1 b 只保留set key1 b)。AOF中只包含了纯指令。

在4.0后,有AOF rewrote机制，写AOF文件,会包含了全量的RDB和增量的写操作。

2.1 AOF优点

1. 丢数据少

2.2 AOF弊端

1. 体量无限变大，旧版中，恢复慢。

3. 持久化理解

系统在10：05 设置一个值，并给出5分钟的过期时间，系统刚刚set完之后redis集群崩溃，10：11分系统重启成功，那么redis中set的值是否还存在?

1. 首先这个key一定过期了，但是是否下盘成功呢?

   • 对于开启RDB,如果set key时，刚好触发RDB，并且RDB成功完成，那么下盘成功.否则下盘不成功
   • 对于开启AOF,需要看写盘频率
     • appendfsync always每次操作都写
     • appendfsync everysec每秒写
     • appendfsync no 完全依赖OS

   无论RDB和AOF都有可能下盘成功或者下盘不成功。当下盘不成功，那么key值重启时必定不存在

2. 假设下盘成功，如果用RDB恢复，在主从架构下

   • 主启动，那么在恢复过程中是会忽略掉已经过期的key

     key值重启时必定不存在

   • 从启动，是不会忽略掉已经过期的key，采用的是惰性删除

     重启的一瞬间是存在的，主从同步后，删除

3. 假设下盘成功，采用AOF进行恢复的话

   当key过期的时候,无论是采用惰性删除还是定期删除,都要在aof中追加 del key的语句,当崩溃的时候,aof文件中还没有del key语句,所以在进行恢复的时候 这个key会被加载到数据库中

   • 主启动

     重启的一瞬间是存在的,如果立马有定时任务扫到了，或者有新的访问过来，检查到key已经过期，那么会被移除掉，会在AOF文件中，增加一条del命令，同步到所有的从节点

   • 从节点启动

     重启的一瞬间是存在的,key的删除依赖主的同步

逻辑图