确定不看？| Redis持久化详解（超详细）

在文章开始，问问你自己，你真的了解redis持久化了吗？redis的持久化到底是什么，通过什么方式，达到什么效果？它的优点缺点。。。等等！

没错，又是我，Java学习小生，下面是我的简介，这一次，探索redis持久化的秘密

博客x主页：不止于梦想 !
文章说明：Redis入门分享
✅系列专栏：【Redis】
本篇内容：Redis的持久化（对所需知识点进行选择阅读呀~）
☕️每日一语：不经一番寒彻骨，怎得梅花扑鼻香。 ☕️
作者详情:作者是一名双非大三在校生，喜欢Java，欢迎大家探讨学习，喜欢的换请给博主一个三连。

笔耕不辍–生命不息，写作不止

Redis持久化概述

为什么需要持久化？

• 在每次学习新知识时，很多人都会有的一个疑问。就是为什么需要，为什么要学，学了有什么作用。其实这个疑问是很重要的。要学习就得搞清楚它为什么存在。
• 那么为什么呢？我们通过学习了解到Redis对数据进行的所有操作都是基于内存的。假设没有持久化的策略（在没学之前给自己的一个假设）。如果遇到了突发情况，数据没来得及存储，例如服务器宕机、或者突发地震？这种情况下数据丢失了，并且无法恢复，怎么办呢？
• 对于这种情况，我们是可以避免的，这就是Redis的持久化，Redis的持久化策略可以在下次重启时利用上次已经存储的持久化文件对数据进行恢复。
• Redis的持久化方式有RDB和AOF两种方式。

RDB（快照）

RDB简介

• RDB（快照/RedisDataBase）方式是Redis持久化的默认的方案，也就是说Redis默认采用了RDB持久化方案了，大家不用过度担心自己数据丢失了（手动滑稽）。
• 指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。
• Redis重启会通过加载dump.rdb文件来恢复数据。

RDB的执行原理

• Redis会（fork）复制一个与当前进程一样的进程。fork（复制）出来的这个新的子进程的所有数据、数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程，来进行持久化。
• 在Redis进行这个操作（fork）的整个过程中，主进程是没有进行I/O操作的。
• 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。这与AOF策略不同，所以
  如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

  

• 上图描写了Redis采用RDB策略的时候，是在当前进程的状态下，复制了一个一模一样的子进程，父进程并不进行操作，而给子进程进行操作，而且在进行快照的时候，并不是直接在RDB文件里进行写入或者其他操作，而是通过新建一个文件，待写完之后，就会用新建的文件替换之前的dump.rdb文件。

RDB文件详细介绍

• 在上面已经提到了dump.rdb文件，这个文件是Redis用来同步数据的，而且是在RDB策略下同步的，AOF另有与之对应的数据文件。
• 文件在Redis启动的目录下，即解压的文件。
• 就像上面所说的，在RDB策略之下，Redis每执行一次数据同步，都会生成一个新的dump.rdb,新生成的dump.rdb会替换掉旧的dump.rdb文件。

配置自动Redis持久化

• 我们可以配置持久化策略：save N M，就是我们对Redis在“N秒内至少有M个改动”就会触发一次RDB持久化操作，生成文件，然后替换原文件。

手动进行RDB

• 在客户端的命令终端，输入save或者bgsave会生成一个快照，从而生成一个新的dump.rdb文件，新文件会自动覆盖原文件。

自动进行RDB

• save N M 配置，我们对Redis在“N秒内至少有M个改动”就会触发一次RDB持久化操作，生成文件，然后替换原文件。

bgsave—写时复制详解(COW)

• 提及bgsave，就得先说save，两者都是RDB，但是save是同步的，而bgsave是异步进行的。同步就是在同一个线程上相互等待，会形成阻塞。异步则是新开一个进程，执行相互不影响，不会形成阻塞。

• bgsave是fork出一个一样的进程，这里说有点重复，其实RDB的执行原理，也就是说，RDB默认采用的就是bgsave方式，这样就不会形成堵塞。
• bgsave的工作流程
  Redis的cow ，cow = copy on write
  Redis创建子进程以后，根本不进行数据的copy，主进程与子进程是共享数据的。主进程继续对外提供读写服务。
  虽然不copy数据，但是kernel会把主进程中的所有内存页的权限都设为read-only，主进程和子进程访问数据的指针都指向同一内存地址。
  主进程发生写操作时，因为权限已经设置为read-only了，所以会触发页异常中断（page-fault）。在中断处理中，需要被写入的内存页面会复制一份，复制出来的旧数据交给子进程使用，然后主进程该干啥就干啥。
  也就是说，在进行IO操作写盘的过程中（on write），对于没有改变的数据，主进程和子进程资源共享；只有在出现了需要变更的数据时，才进行copy操作。

RDB的数据恢复

• 通过脚本将Redis产生的dump.rdb文件备份(cp dump.rdb dump_bak.rdb)，每次启动Redis前，把备份的dump.rdb文件替换到Redis相应的目录(在redis.conf中配的的dir目录)下，Redis启动时会加载dump.rdb文件，并且把数据读到内存中。

AOF(Append-Only File)

AOF简介

• 为什么存在？从上面我们已经看出，RDB的持久化方式可能导致数据的丢失。AOF出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF原理初步

• AOF 持久化功能的实现可以分为命令追加（append）、文件写入、文件同步（sync）三个步骤，这里只大概说明，不严格区分。

• Redis以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，追加到appendonly.aof文件中。

  

• 在这个过程中，只能追加文件但不可以改写文件。

  

• redis启动之初会读取该文件重新构建数据，换一个说法就是redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

  

  appendonly.aof文件简介

  • appendonly.aof是AOF持久化方式的默认文件。
  • 在AOF持久化的方式下，当redis的进程进行写操作时（读操作不处理），会把写操作的命令追加到appendonly.aof文件中，待下次重启redis时进行数据结构和数据的恢复处理。
  • 在默认情况下（即持久化方式为RDB方式）的情况下，该文件并不存在，因为没人进行处理过，没有数据存储，也就没有创建文件。

    
    
    当appendonly设置为yes，即开启AOF持久化方式时，redis就创建了appendly.aof文件，即使你重新关闭了AOF，这个文件也还是会存在。用于追加写操作命令，下面是刚创建文件时文件里面的内容。
    

开启AOF持久化策略

方法一

• 在redis.conf配置文件下有appendonly，把no改为yes，再重启即可。

  • 这里可能不太好找，使用vim打开redis.conf文件时，可以在命令行输入“:/appendnoly”即可，如果下方显示Insert，你可以点击一下Esc键，然后打上双引号。

• 使用配置文件方式开启AOF持久化方式是持久的

  
  
  找到appenonly，默认为no，改为yes。执行上述操作，输入wq保存退出，重启。

方式二

• 在客户端开启AOF策略，首先开启redis-server服务，然后使用redis-cli对客户端进行连接，再使用config get appendonly 查询AOF是否已经开启，没有则使用config set appendonly yes 把appendonly的no改为yes，即可开启AOF持久化策略。但是使用这个方法只是开启一时的AOF，怎么解释呢？就是说你这次开启，下一次重启之后，还是会关闭。
  
• 重启之后，还是恢复了默认的方式。
  

AOF的数据恢复

简介

• 首先，什么叫做AOF的数据恢复呢？AOF的数据恢复就是经过前面的AOF持久化保存在appendonly.aof文件的写操作命令，在redis重启的时候，会对文件进行读取和执行，以此来恢复到上次退出redis服务之前的状态。
• 在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。

AOF重写机制

情景

• 大家不妨想一个问题，AOF持久化采用的是追加的方式，那么文件会不会越来越大呢？当文件越来越大，直到装不下。程序崩溃。怎么避免这个问题呢？

解决方案

• 当追加的命令越来越多的时候，存储大小到了某个指定的阈值。为了解决这个问题，就引出了AOF的重写机制。

AOF重写简介

• 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
• 什么叫做最小指令集呢？最小指令集就是把重复的命令（写）归为一个。

set string 1
set string 2
set string 3 

上面的代码数据类型和方法都一样，那么这就是重复的命令、最小指令集就是把这写抽离出来，如下面

set string (1、2、3）
或者
set（string 1、string 2、string 3）.

重写就是压缩文件。

AOF重写的过程

• AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
• Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。当然，也可以在配置文件中进行配置。

AOF小结

• AOF持久化的方式是需要手动开启的。
• AOF持久化的完整性比RDB持久化数据的完整性高。

Redis持久化小结

• Redis的一种使用方式，就是拿来做缓存，如果是拿来做缓存，可以把redis的持久化关闭。
• Redis常用的持久化方式并不是单独使用，而是一起使用的，这个不冲突，Redis提供这种持久化方式，在这种模式下，RDB一般用来做备份，而AOF提供高效的持久化方案。