Day06:缓存持久化
缓存持久化redis做为缓存,数据的持久化是怎么做的?
在Redis中提供了两种数据持久化的方式:1、RDB 2、AOF
方式一:RDB
RDB(Redis Database Backup file),redis数据备份文件,也叫Redis数据快照,就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后,从磁盘读取快照文件,恢复数据。
最基本的操作是先使用redis的客户端执行命令,命令有save和bgsave,这两个命令都可以手动执行RDB文件的生成。其中save是用主进程来执行RDB,bgsave是用子进程来执行RDB。假如文件比较大,使用主进程会阻塞其他线程的命令,所以一般在项目中是使用bgsave来执行RDB。
https://i-blog.csdnimg.cn/direct/5024b648db7d452a829d6975e4be6547.png
redis提供了RDB触发机制,在redis.conf配置文件中可以找到相干配置,比如save 900 1 就是900秒内,如果至少有1个key被修改,则执行bgsave。
https://i-blog.csdnimg.cn/direct/8cdd8efc55014991a6fba73c85f9cb5b.png
RDB的执行原理:
主进程操作虚拟内存,虚拟内存基于页表的映射关联到物理内存,这样就能实现对物理内存读写的操作。当执行bgsave的时候会fork一个子进程,仅仅是把页表拷贝到子进程。这样无需拷贝内存中的数据,子进程和主进程就能实现内存空间共享,速率非常快。子进程拿到页表之后就可以把读到的数据写入到磁盘中,这就是异步持久化。但是子进程在写RDB文件的过程中,主进程可以吸收用户的哀求修改内存中的数据,这就大概读取脏数据。
https://i-blog.csdnimg.cn/direct/36c66fa4bc8e4992a08dfcb28fc75c22.png
为了避免这种环境发生,fork底层采用copy-on-write技能。在fork的时候会把共享的数据标记为read-only,任何一个进程只能读数据。当主线程写数据的时候,会先拷贝一份数据,然后再去完成写操作。一旦完成拷贝操作之后,主进程读数据的时候也会读取拷贝的数据。
方式二:AOF
AOF(Append Only File,追加文件),Redis处理的每一个写命令都会记录在AOF文件中,AOF可以看作是命令日记文件。它默认是关闭的,可以在redis配置文件中开启。在redis中有三种记录频率,也就是刷盘计谋。Always、everysec和no。
Always会立即记录每次执行的写命令,可靠性高险些不丢失数据,但是性能差。everysec每秒刷盘一次,最多丢失一秒数据。no由操作体系决定符合将缓存数据写入到磁盘。一般在项目中会采用everysec。
由于AOF记录的是命令,所以AOF比RDB文件大的多。而且AOF会记录对同一个key的多次写操作,但是只有最后一次写操作才有意义。通过执行bgrewriteaof命令,对当前的AOF文件重写,就可以使用最少的命令达到相同的效果。也可以通过redis.conf自动触发阈值,设置auto-aof-rewrite-percentage的值,也就是AOF文件比前次增长超多百分之多少会触发重写。设置auto-aof-rewrite-min-size的值,AOF文件体积最小多大以上触发重写。
RDB与AOF对比
RDB和AOF都有优缺点,如果对数据安全性要求高,在实际开辟中每每联合两者使用。
[*]持久化方式,RDB对整个内存做快照,AOF记录每次执行的命令。
[*]数据完整性,RDB记录的数据不完整,两次备份之间会丢失。AOF相对完整,取决于刷盘计谋。
[*]文件巨细,RDB会有压缩,文件体积小。AOF记录命令,文件体积很大。
[*]宕机恢复速率,RDB由于文件小,恢复速率很快。AOF文件大,恢复速率很慢。
[*]数据恢复优先级,AOF的数据完整性更好,所以它的恢复优先级更高。
[*]体系资源占用,RDB的体系资源占用比较高,写操作的时候会大量占用CPU和内存的斲丧。但是AOF重要占用磁盘I/O,但是当AOF重写的时候也会占用大量的CPU和内存资源。
[*]使用场景,假如业务可以容忍数分钟的数据丢失就可以使用RDB,速率快。如果对数据安全性要求高,就可以使用AOF,但是一般环境下两者都要开启。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页:
[1]