Redis篇——Redis持久化，学习Redis的重点中的重点！涵盖RDB和AOF持久化机制详细的介绍和对比，保姆级教程！一篇文章帮你彻底拿下！_moderdb

了解持久化

Redis的持久化

一、前请了解
Redis是内存数据库，如果不将内存中的数据状态保存到磁盘中，那么一旦服务器进程中断，服务中的数据状态也会消失。因此，Redis提供了持久化的功能！！！！！！

二、重要性
在面试和工作中，是非常常用和高频提问的，尤其是要学扎实RDB和AOF！！！！！！

同时开启两种持久化的方式

1.在这种情况下，当Redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常的情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

2、RDB数据不实时，同时使用两者时服务器重启也只会找AOF文件，但是还是不建议使用AOF，因为RDB更适合用于备份数据库（AOF在不断地变化不好备份），另外RDB还可以快速的重启，避免启动Redis的时候加载大量的AOF文件，另外RDB不会存在恶意篡改的风险。

RDB(Redis Database)

RDB持久化的底层细节

一、了解什么是RDB
在指定的时间间隔内对数据进行快照存储，也就是Snapshot快照，它恢复时是将快照文件直接读到内存里

二、工作机制
快照原理-Redis使用操作系统的多进程COW（Copy On Write）机制来实现快照持久化。

Redis会单独创建（fork）一个子进程，会先将数据写入到一个临时的文件中，等待持久化结束后，再用这个临时文件替换上次持久化好的文件。
了解Redis是如何fork子进程的？
Redis在持久化时会调用glibc的函数fork产生一个子进程，快照持久化完全交由子进程来处理，父进程继续处理客户端请求。子进程刚产生时，它和父进程共享内存里面的代码段贺数据段。
子进程做数据持久化，不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端的请求，然后对内存数据结构进行不间断的修改。
这个时候就会使用操作系统的COW机制来进行数据段页面的分离。数据段是由很多操作系统的页面组合而成的，当父进程对其中的一个页面的数据进行修改的时，会将被共享的页面复制一份分离出来，然后对这个复制页面进行修改。这个时候子进程相应的页面是没有变化的，还是进程产生时那一瞬间的数据。

三、RDB优缺点
优点：
1、整个过程中，主进程是不进行IO操作的，这样就确保了极高的性能
2、如果需要大规模数据的恢复，且对于数据恢复的完整性不是非常敏感的，那么RDB方式要比AOF方式更加高效。

缺点：
1、需要一定的时间间隔进行操作，如果Redis意外宕机，最后一次持久化后的数据可能丢失
2、fork进程的时候，会占用一定的内存空间

我们系统中默认是使用RDB，一般情况下是不需要修改这个配置的！

四、rdb保存的文件
在生产环境中，一般都会把这个rdb文件备份一下
在redis.conf中默认是dump.rdb文件，这里要和aof进行区分，aof是以.aof结尾

测试使用RDB存储数据

1、修改redis.conf配置文件中快照配置
在snapshot快照配置下，修改rdb持久化的方式，现在修改成了60秒内如果对key修改了5次，就对数据进行持久化

2、查看本地是否存在dump.rdb文件，先删除掉

3、保存配置文件中的修改
在连接上Redis的终端输入命令

save

4、一分钟内增加5条数据

5、发现bin下多出了刚刚删除掉的dump.rdb文件

6、关闭redis连接，并通过ps命令查看是否确定关闭了redis的进程

7、重新连接redis，测试还能否拿到刚刚退出之前设置的数据

[root@guohui bin]# redis-server ghconfig/redis.conf 
[root@guohui bin]# redis-cli -p 6379
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> get  k1 #确实可以拿到！！！！！！！
"v1"
127.0.0.1:6379> get k2
"v2"

8、性能建议
RDB文件只用作后备用途，建议只要15分钟备份一次就够用了，只保留save 900 1这条持久化规则即可

生成dump.rdb文件的机制

1、save的规则满足的情况下，自动出发rdb规则
2、执行flushall命令，也会触发！
3、退出redis，也会生成dump.rdb文件

最后都会生成一个dump.rdb文件

利用rdb恢复数据

1、将dump.rdb文件放到redis的启动目录下，redis启动的时候会自动检查该文件，恢复其中的数据！！！！！！简单！！！！！！

2、、查看dump.rdb文件需要存储的位置

config get dir

AOF(Append Only File)

AOF持久化机制底层细节

一、认识什么是AOF
AOF持久化方式记录每次对服务器写的操作，当服务器重启时候会重新执行这些命令来恢复原来的数据，AOF命令以Redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大！
简单来说就是将我们的所有的命令都记录下来，相当于一个history，恢复数据的时候，把这个文件再执行一遍！

AOF重写：
Redis提供了bgrewriteaof指令用于对AOF日志进行瘦身。原理是开辟一个子进程对内存进行遍历，转换成一系列Redis的操作指令，序列化到一个新的AOF日志文件中。序列化完毕后再将该操作期间发生的增量AOF日志追加到这个新的AOF日志文件后，追加完毕后就立即替代旧的AOF日志文件了，至此瘦身工作就完成了！

二、工作机制

以日志的形式来记录每个写的操作，将Redis执行过的所有指令记录下来（注意，读的操作是不会被记录的），只需追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将指令从前到后执行一次，以完成数据的恢复工作！

了解fsync：
AOF日志是以文件的形式存在的，当程序对AOF日志文件进行写操作的时候，实际上是将内容写到了内核为文件描述符分配的一个内存缓存中，然后内核会异步将脏数据刷回磁盘中。
那么这个时候如果机器突然宕机了，AOF日志内容可能还没来得及刷到磁盘中，这个时候，就会出现日志丢失。应该怎么办呢？
Linux的glibc提供了fsync(int fd)函数可以将指定的文件的内容强制从内存刷到磁盘中。只要Redis进程实时调用fsync函数就可以保证AOF日志不丢失。但是fsync是一个磁盘IO操作，它很慢！生产环境中一般设置成每隔1s左右执行一次fsync操作。
Redis同样也提供了另外两种策略。一个是永远不fsync，让操作系统来决定适合同步磁盘，很不安全；另一个是来一个指令就fsync一次，这样非常耗性能，非常慢，在生产环境中基本不会使用！

三、AOF保存的文件
在redis.conf配置文件中的APPEND ONLY MODE模块中，默认保存的文件为appendonly.aof

测试使用AOF

1、先去配置文件中开启AOF的配置，Redis默认是不开启的

2、修改了配置文件，重启redis服务
执行shutdown和exit命令

3、重启redis服务

4、发现在/usr/local/bin目录下多了一个文件夹

5、进入到这个文件夹，发现里面多了些文件

这个文件的作用就是把我们执行的各种写入的语句都保存下来，当我们下一次再启动Redis服务的时候 ，会将这些语句再次执行一次

6、如果我们这个.aof的文件受到恶意的破坏，也有办法修复，可以还原回原来的状态
如果.aof文件错误，redis是无法启动的，但是我们redis给我们提供了一款修复工具

修复的命令

AOF优缺点

一、优点
1、可以修改配置，设置每次修改都同步，文件的完整性更加好！

二、缺点
1、大数据文件下，aof的修复效率远远低于rdb
2、aof的运行效率同样也是不如rdb，所以我们redis默认是rdb的形式来进行持久化！！！！！！
 

至此，关于Redis的持久化机制，你已经全部掌握了，关于持久化机制，如果继续往底层研究还是相当深的，如果大家感兴趣，可以在评论区一起交流一下，一起研究下更深入的部分~

后续还会持续更新相关技术点，敬请期待~