redis持久化实现原理

「爱情、让人受尽委屈。」 2023-10-07 08:33 10阅读 0赞

> **RDB**
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70][]
> 
> **rdb持久化原理：**
> 
> 会涉及到操作系统底层的fork调用，详情查看：[https://zhangxueliang.blog.csdn.net/article/details/104076571][https_zhangxueliang.blog.csdn.net_article_details_104076571]
> 
> 会fork出一个子进程用于持久化。
> 
> 当redis主进程发生数据修改的时候，会触发内核级别的写时复制操作，写数据到持久化文件是子进程来完成的，数据的增删改是在父进程中进行的，所以redis的持久化是fork+copy on write来实现的。
> 
> 比如8点fork出一个子进程用于持久化操作，此时子进程拷贝的是8点时的数据，父子进程的数据修改，彼此都不可见。假如10点redis数据发生了修改，此时会由内核的写时复制机制触发数据复制操作，将引用指向新的数据，此时子进程的引用还是指向旧数据。写时复制不是为了数据同步，而是数据隔离。
> 
> fork出来的子进程会一直等到数据持久化做完后才销毁。每次持久化开始时都会fork出一个子进程。每次拍快照（持久化）都是当前时间点的全量数据覆盖之前的快照数据，如果快照采用增量更新的方式的话，需要在内存中判断哪些数据有更新哪些没更新，反而消耗CPU资源。
> 
> 拷贝引用的成本比拷贝数据的成本低很多，因为一个引用的大小是4个字节，但引用指向的数据可能是一个数组几百个字节。
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 1][]
> 
> **redis RDB持久化配置方式：**
> 
> ![20200123172209562.png][]
> 
> 如果想关闭持久化，只需在配置文件redis.conf中配置：
> 
>     save ""
> 
> redis.conf配置文件中配置持久化文件相关信息：
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 2][]
> 
> **RDB的弊端：**
> 
> ①不支持拉链。由于只有一个dump.rdb持久化文件，所以会丢失前些天的数据，需要手工将dump文件拷贝出来。比如：我需要某一天的dump文件，如果不手工干涉的话，也许已经被覆盖了。
> 
> ②丢失数据相对多一些。时点与时点之间的窗口数据容易丢失，比如8点得到一个dump.rdb，8：15要落一个rdb，结果挂机了。
> 
> **RDB的优势：**
> 
> 类似于Java中的序列化，恢复数据的速度较快。想象一下，传输一个json数据然后解析成对象load到内存快还是直接传输一个二进制字节数组直接就怼到了内存快？用大腿想都知道是后者啦！
> 
> 正是由于RDB的弊端，才有了AOF：Append Only File 的持久化机制。

> **AOF**
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 3][]
> 
> 将redis的写操作记录到文件中。类似于MySQL中的redo log和binlog一样。这样的话，丢失数据就会少啦。
> 
> 在redis中，RDB和AOF可以同时开启，但是AOF优先，只会使用AOF做重启后的数据恢复。
> 
> aof执行日志文件中的命令，速度相对rdb要慢。但丢失数据相对rdb少。
> 
> aof天然的弊端：
> 
> ①日志体量无限变大；
> 
> ②恢复慢。
> 
> 优点如果能保住，日志还是可以用的，需要设计一个方案让日志，AOF足够小。
> 
> 4.0以前通过日志重写来实现：
> 
> ①删除抵销的命令
> 
> ②合并重复的命令
> 
> 4.0以后也是通过日志重写来实现，只不过进行了优化：
> 
> ①将老的数据RDB到aof文件中，存储的是二进制格式的日志数据。
> 
> ②将增量的以redis指令的方式append到aof日志文件中。
> 
> AOF是一个混合体，利用了RDB的快和日志的全量。
> 
> redis 4.0 以后，AOF中包含RDB全量快照数据，增加记录新的写操作。
> 
> **开启AOF**
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 4][]
> 
> IO流中为什么要flush一下才能将数据写到磁盘，因为磁盘IO操作都是由操作系统内核来进行的，数据先是下入到内存的buffer中，flush就是将数据从buffer中刷到硬盘。redis中也是如此：
> 
> ![20200123201009897.png][]
> 
> always：每次发生数据变更，立即持久化到硬盘
> 
> ererysec：每秒持久化一次，也就是每秒调一次flush将buffer数据刷到硬盘
> 
> no：等待OS自己将数据刷到硬盘，buffer一满OS就会刷到硬盘。
> 
> 效率对比：always < everysec < no
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 5][]
> 
> no-appendfsync-on-rewrite默认是no：可能会发生丢数据的情况。但不会与自己的子进程争抢IO操作权。
> 
> ![20200123201835573.png][]

![20200123203115274.png][]

![20200123203237130.png][]

![20200123203426482.png][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200123182010386.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70
[https_zhangxueliang.blog.csdn.net_article_details_104076571]: https://zhangxueliang.blog.csdn.net/article/details/104076571
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200123170313418.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70
[20200123172209562.png]: https://img-blog.csdnimg.cn/20200123172209562.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200123172627340.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200123182057260.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200123200340927.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70
[20200123201009897.png]: https://img-blog.csdnimg.cn/20200123201009897.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/20200123201552290.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly96aGFuZ3h1ZWxpYW5nLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70
[20200123201835573.png]: https://img-blog.csdnimg.cn/20200123201835573.png
[20200123203115274.png]: https://img-blog.csdnimg.cn/20200123203115274.png
[20200123203237130.png]: https://img-blog.csdnimg.cn/20200123203237130.png
[20200123203426482.png]: https://img-blog.csdnimg.cn/20200123203426482.png