在前一篇文章中,已经介绍了Redis的基础数据结构,这篇文章将继续介绍Redis的持久化原理。
”
![1270c56301c0810528c0c8da30baa9a8.png](https://i-blog.csdnimg.cn/blog_migrate/ae37149c43cf64dc6a0496c3a90a01d7.jpeg)
面试知识点快速浏览
简介
众所周知Redis的所有数据都存在于内存之中,这就会存在因内存问题而导致的数据丢失,为了避免这一问题,可采取Redis的持久化机制来解决这一问题。
详解
Redis持久化有两种方式,分别是RDB(又称快照)与AOF。对于两种方式各有优缺点,具体如下:
RDB:全量一次同步内存中所有序列化的二进制数据,同步慢,数据较小。
AOF:增量同步操作指令,同步较快,数据量随时间增加而增多,需定期进行AOF文件重写,以便减小日志文件。
RDB原理
SAVE:该命令会阻塞当前Redis服务,导致Redis服务不可用,直至RDB持久化进程完毕,所以一般都不采取该方式进行RDB持久化。
BGSAVE:当使用该命令进行RDB持久化时,Redis会fork产生一个子进程,由子进程进行RDB持久化操作,父进程接受客户端的操作请求。子进程只会遍历读取内存中的数据,写入磁盘,并不会修改数据,若父进程在子进程读取数据过后进行了数据修改,子进程就会与父进程存在数据不一致的问题。
Copy on Write:众所周知Redis是单线程程序[1],文件IO操作不能进行多路复用,于是在BGSAVE进行RDB持久化时Redis采用操作系统的Copy on Write[2]机制进行RDB持久化。
单独使用RDB持久化,存在日志文件丢失风险
AOF原理
AOF日志存储的是,Redis执行的顺序写指令。当开启AOF持久化时,Redis会先执行数据的写指令,再将指令写入AOF日志中。
fsync:实际情况中,AOF机制会先将Redis写指令写入内存缓冲区中,再根据配置情况,定时调用fsync将缓冲区文件写入AOF日志中。我们可以根据实际情况设置fsync频率:
- always:每次修改,立即提交磁盘。该方式数据完整性良好,但是IO开销大,影响效率.
- everysec: 每秒同步一次到磁盘。该方式只会丢失一秒内的数据,
- no: 从不同步到磁盘。
思考
从上述的原理中,可以看出无论是RDB还是AOF,都存在一定的缺点。
在日常操作中,一般都是从AOF日志中来恢复数据,因为RDB会丢失大量数据。但是AOF恢复数据又会花费较长时间。
于是从Redis4.0开始,Redis开始支持混合持久化。即将RDB与AOF结合使用,RDB负责定时全量持久化数据,AOF负责记录最后一次RDB后的增量日志。使得Redis的数据恢复在恢复效率与数据完整性之间取得一个完美的平衡点。
Redis系列推荐
Redis01——Redis究竟支持哪些数据结构
关注我
关注公众号「Java面点」,获取更多Java面试知识点
参考资料
[1] Redis6.0开始支持多线程版本,除非特别提及,都默认为单线程版本: https://my.oschina.net/javayou/blog/3114474
[2] Copy on Write: https://blog.csdn.net/weixin_39554266/article/details/82835478