by shihang.mai
凡是存储,都有快照/副本、日志
1. RDB
RDB(redis db)描述的是快照/副本
Linux存在父子进程,而且子进程可以看到父进程的数据。子进程和父进程变量之间互不影响。
redis RDB例如在8:00时,触发RDB
-
redis的内存fork()出一个子进程如图,这时复制的只是指针,速度快
-
当有请求修改key=a的值为w时,内核用了copy on write机制,在内存中重新在另外一个地址上有一个值w,然后key=a重新指向w(上图红色线),这样做修改并不会影响子进程。这样做内存也用得少
-
这样做达到了速度快,内存也用得少。也保证了redis的时点性
1.1 RDB弊端
-
只有一个dump.rdb,即只有一个备份文件。
-
时点之间的数据丢失。
1.2 RDB优点
- 类似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优点
- 丢数据少
2.2 AOF弊端
- 体量无限变大,旧版中,恢复慢。
3. 持久化理解
系统在10:05 设置一个值,并给出5分钟的过期时间,系统刚刚set完之后redis集群崩溃,10:11分系统重启成功,那么redis中set的值是否还存在?
-
首先这个key一定过期了,但是是否下盘成功呢?
- 对于开启RDB,如果set key时,刚好触发RDB,并且RDB成功完成,那么下盘成功.否则下盘不成功
- 对于开启AOF,需要看写盘频率
- appendfsync always每次操作都写
- appendfsync everysec每秒写
- appendfsync no 完全依赖OS
无论RDB和AOF都有可能下盘成功或者下盘不成功。当下盘不成功,那么key值重启时必定不存在
-
假设下盘成功,如果用RDB恢复,在主从架构下
-
主启动,那么在恢复过程中是会忽略掉已经过期的key
key值重启时必定不存在
-
从启动,是不会忽略掉已经过期的key,采用的是惰性删除
重启的一瞬间是存在的,主从同步后,删除
-
-
假设下盘成功,采用AOF进行恢复的话
当key过期的时候,无论是采用惰性删除还是定期删除,都要在aof中追加 del key的语句,当崩溃的时候,aof文件中还没有del key语句,所以在进行恢复的时候 这个key会被加载到数据库中
-
主启动
重启的一瞬间是存在的,如果立马有定时任务扫到了,或者有新的访问过来,检查到key已经过期,那么会被移除掉,会在AOF文件中,增加一条del命令,同步到所有的从节点
-
从节点启动
重启的一瞬间是存在的,key的删除依赖主的同步
-
网友评论