本系列会持续输出Redis相关的知识整理，提升自己的同时希望能帮助到有需要的朋友，持续输出…持续输出…持续输出…
专题目录：目录传送 前言在前面的文章我们简单介绍了Redis的数据结构的使用和简单的应用场景，希望能够帮助部分有需要的人。
介绍在介绍持久化之前我们先来说说Redis为啥这么高性能？为啥需要持久化操作？
因为它所有的数据都在内存中，所有的运算都是内存级别的运算，大家也都知道存放于内存中的数据都是极其不安全的，收外界因素干扰过多，因此我们才需要 持久化操作。
下面我们来简单介绍一下持久化操作：
redis的持久化有两种方式 RDB快照(snapshot) 和 AOF(append-only file)
RDB快照(snapshot)在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。 你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次 数据集。 比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次 例如：save 60 1000 关闭RDB只需要将所有的save保存策略注释掉即可 
还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件， 每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。 save是同步命令，bgsave是异步命令，bgsave会从redis主进程fork（fork()是linux函数）出一个子进程 专门用来生成rdb快照文件
我们来看看rbd快照文件 
他会把我们的数据进行压缩存储。
save与bgsave对比:
命令savebgsaveIO类型同步异步是否阻塞redis其它命令是否,会生成子进程复杂度O(n)O(n)优点不会消耗额外内存不阻塞客户端命令缺点阻塞客户端命令需要fork子进程，消耗内存 AOF（append-only file）快照功能并不服非常耐久的：如果Redis因为某些原因而造成故障停机，那么服务器将丢失最近写入到Redis而未保存到快照中的那些数据 例如：save 60 1000 进行一次快照后 在第70S的时候发生了故障，那么我们将丢失掉这中间10S的数据，在这里Redis新增了一种完全耐久的持久化方式：AOF持久化，它会将修改的每一条指令记录到文件appendonly.aof中。
- 打开AOF：在配置文件中将 # appendonly yes 注释
从现在开始每当Redis执行一个改变数据集的命令时，这个命令就会被追加到AOF文件的末尾。这样的话当Redis发生故障重新启动时，程序可以通过执行AOF文件中的命令来大刀重建数据的目的。 你可以配置Redis多久才将数据fsync到磁盘一次： - appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。 - appendfsync everysec：每秒 fsync 一次，足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。 - appendfsync no：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。 ----------------------------------------------------------------------------------------- 推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。
我们来操作一下，首先打开aof，将上述描述的注释放开重启即可。
连接客户端进行set 一条记录: set test1 test1 查看AOF文件: vi appendonly.aof 
有人可能会用$5是啥意思，这些事Redis用来计算存储空间的，我们刚刚test1实际长度就是5因此这里也会进行记录下来。
AOF 重写AOF文件中可能有太多没用指定，所以AOF会根据内存的最新数据生成aof文件，例如我们执行的get等操作也会记录在里面的。另外我们也可以指定AOF自动重写的频率 如下两个配置可以控制AOF自动重写频率 1). auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就很快，重写的意义不大 2).auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写 我们也可以进行收到重写：执行命令:bgrewriteaof 此处，AOF重写Redis也会fork一个子进程去进行，不多对Redis正常命令有太多影响。
- RDB和AOF，对比
需要注意的是：redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据，因为aof一般来说数据更全一点。
混合持久化在Redis4.0的时候推出了混合持久化，重启Redis时候，我们很少使用RDB来恢复内存状态，因为会丢失大量数据，我们通常使用AOF日志重放，但是重放AOF日志性能相对RDB来说要慢很多，这样在Redis实例很大的情况下，启动需要花费很长时间。Redis4.0因此推出了混合持久化。
- 打开配置：# aof-use-rdb-preamble yes
如果开启了混合持久化，AOF在重写时，不在单纯将内存时间转化为命令的格式写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令混合存放，都写入新的AOF文件，新的AOF文件，完成新旧两个AOF文件的替换。 于是在Redis重启的时候，可以先记载RDB内容，然后在重放增量AOF日志就可以完全替代之前的AOF全量文件重放，效率得到大幅度提升。
- 混合存放数据格式
实例：
1.按照上述打开配置文件放开注释改为yes 2.连接客户端执行命令bgrewriteaof 3.在进行插入一条测试数据。
完成上述后我们在来看看aof文件的数据： 
本篇就介绍到此，如果有不对的地方，还恳请各位指正，再次感谢！
