zoukankan      html  css  js  c++  java
  • 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主节点是不进行数据初始化的,持久化操作主要在从节点进行。从节点是备份节点,没有来自客户端请求的压力,它的操作系统资源往往比较充沛。

    郭慕荣博客园
  • 相关阅读:
    CodeForces Gym 100935G Board Game DFS
    CodeForces 493D Vasya and Chess 简单博弈
    CodeForces Gym 100935D Enormous Carpet 快速幂取模
    CodeForces Gym 100935E Pairs
    CodeForces Gym 100935C OCR (水
    CodeForces Gym 100935B Weird Cryptography
    HDU-敌兵布阵
    HDU-Minimum Inversion Number(最小逆序数)
    七月馒头
    非常可乐
  • 原文地址:https://www.cnblogs.com/jelly12345/p/14458200.html
Copyright © 2011-2022 走看看