Redis持久化原理总结

1:快照原理
Redis使用操作系统的多进程COW(copy on write)机制来实现快照持久化,Redis在持久化时会调用glibc的函数fork产生一个子进程,快照持久化完全交给子进程来处理,父进程继续处理客户端请求。子进程刚刚产生的时,它和父进程共享内存里面的代码段和数据段。子进程做数据持久化,不会修改现有的内存数据结构,它只是对数据结构进行遍历读取,然后序列化写到磁盘中。但是父进程会继续处理客户端的读写请求,然后对内存数据结构进行不断的修改。这时子进程相应的页面是没有变化的,还是进程产生时的那一瞬间的数据。子进程因为数据没有变化,它能看到的内存里面的数据在进程产生的一瞬间就凝固了,再也不会改变,这也是Redis持久化叫“快照"的原因。接下来子进程就可以非常安心的遍历数据,进行序列化写磁盘了。

rdb的劣势:
①:fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑
②:虽然Redis在fork的时候使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能
③:被备份周期在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照后的所有修改
rdb的优势:
①:适合大规模的数据恢复
②:对数据完整性和一致性要求不高更适合使用
③:节省磁盘空间
④:恢复速度快

2:AOF原理

AOF日志存储的是Redis服务器的顺序指令序列,AOF日志只记录对内存进行修改的指令记录。Redis在长期运行的过程中,AOF日志会越来越长,所以需要对AOF日志文件进行瘦身。Redis提供了bgrewriteaof指令用于对AOF日志进行瘦身,其原理就是开启一个子进程对内存进行遍历,转化成一系列的Redis的操作指令,
序列化到一个新的AOF日志文件中,序列化完毕后再将操作期间发生的增量AOF日志追加到这个新的AOF日志文件中,追加完毕后就立即代替旧的AOF日志文件了,瘦身工作也就完成了。AOF日志是以文件的形式存在的,当程序对AOF日志文件进行写操作时,实际上是将内容写到了内核为文件描述符分配的一个内存缓冲中,然后内核会异步将数据刷回到磁盘的。Linux的glibc提供了fsync(int fd)函数可以将指定文件的内容强制从内核缓存刷到磁盘。只要Redis进程实时调用fsync函数就可以保证Aof日志不会丢失。但是fsync是一个磁盘IO操作,他很慢。一般在生产环境Redis同程是每隔1S左右同步一次,当然是可以进行配置的。

以日志的形式来记录每个写操作(增量保存),讲Redis执行过的所有写指令
记录下来。
aof和rdb同时开启,系统默认取AOF的数据(数据不会存在丢失)
优势:
备份机制更稳健 丢失数据概率更低
可读的日志文本,通过操作AOF稳健,可以处理误操作

劣势:
比起RDB占用更多的磁盘空间
恢复备份速度更慢
每次读写都同步的话 有一定的性能压力
存在个别bug,造成恢复不能

总结:
快照是通过开启子进程的方式进行的,他是一个比较耗资源的操作。
①:遍历整个内存,大块写磁盘会加重系统负载。
②:AOF的fsync是一个耗时的IO操作,它会降低Redis性能,同时也会增加系统IO负担。
所以通常在生产环境中,Redis主节点是不进行数据初始化的,持久化操作主要在从节点进行。从节点是备份节点,没有来自客户端请求的压力,它的操作系统资源往往比较充沛。

郭慕荣博客园
原文地址:https://www.cnblogs.com/jelly12345/p/14458200.html