redis是一种基于内存的非关系型数据库,内存虽然快但是数据也更易丢失,所以redis提供了两种持久化方式,分别是RDB和AOF,今天就介绍下这两种持久化方式以及原理
rdb是一种快照式的存储也是redis默认的持久化策略,它将内存中的数据持久化到磁盘中且能做到不影响redis的性能;其有两种持久化方式,一个是阻塞式的持久化(save)另一个是非阻塞式后台的持久化(bgSave);
利用linux父子进程的概念,持久化时fork一个子进程,但并没有复制父进程内存中的所有数据,而只是移动了指针,利用了copy on write机制只在write时才真正的复制数据,速度快;父进程不需要再做其他IO操作,所以RDB持久化方式可以最大化redis的性能;
注意:需要明确linux父子进程之间是相互隔离的,开启save过后子进程只专注于文件的落盘操作,此时主进程仍然可以接收客户端请求,只是在有写操作时利用copyonwrite机制复制数据
RDB恢复数据的时间快,bgsave的时候也不会影响redis对外提供的性能,但是会存在较大丢失数据的风险;并且不支持拉链存储,即最新的rdb文件会覆盖掉历史版本的文件,硬盘永远只有一份持久化文件
一种通过配置可以做到几乎实时的写入式持久化方式,相对应的其会影响系统的性能;
将每个redis指令都写入aof文件,并且具有重写能力:随着同步操作越来越多aof文件的大小也会越来越大,这时会触发重写机制;redis可以在不打断服务客户端的情况下, 对 AOF 文件进行重建(rebuild)。执行 BGREWRITEAOF 命令, Redis 将生成一个新的 AOF 文件, 这个文件包含重建当前数据集所需的最少命令。需要注意的是redis4.0以后重写是会把rdb文件写到aof文件里面,只追加rdb过后的命令;这样大大提高了效率
可以配置 Redis 多久才将数据 fsync 到磁盘一次;redis提供了三种方式:
AOF更安全,更不易丢数据,但是AOF恢复数据没有RDB快,且AOF理论上会存在文件一直无限变大的可能,即使有重写和合并RDB机制,但当redis运行的时间足够长时还是会存在文件过大的问题
分析:在redis重新时主进程必然也会存在有大量写入操作的可能,两者都会操作磁盘,影响性能;该配置意思是在是否使用no这种刷盘机制,上面也结束了,no这种机制是最快但是最不可靠的写入方式;redis默认为no,即表示在重新时仍然不使用no这种方式,宁愿阻塞等待也不愿意丢失数据;为yes的话则表示重写时主进程使用no这种刷盘机智;
注意:如果aof文件在中间损坏,redis仍将退出并出现错误;
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70000523/viewspace-3149075/ ,如需转载,请注明出处,否则将追究法律责任。