很多时候我们需要将Redis进行持久化也就是说将存储在内存中的数据写入到硬盘中，大部分原因是为了之后重用数据（比如说机器重启），或者是为了防止系统故障而进行的备份。
Redis提供两种持久化的机制，一种是快照持久化（RDB） ，另一种是只追加文件持久化（AOF） 。下面我们分别来介绍下面两种持久化机制。
一、RDB持久化
我们可以通过创建快照来获取存储在内存中的数据在某个时间点上的副本，Redis在创建快照后，我们可以将快照复制到其它的服务器上从而创建相同数据的服务器副本；或者是将快照留在原地用于机器重启的时候使用。
快照持久化是Redis默认采用的持久化方式。
二、AOF持久化
相比RDB持久化，AOF持久化的实时性更高，所以大多数使用的都是AOF持久化，Redis默认不开启AOF持久化，可以通过appendonly参数来开启AOF持久化：
appendonly yes
开启了AOF持久化之后，当执行会发生数据修改的命令时，Redis都会将该命令写入到aof文件中。AOF文件的保存位置和RDB文件的位置一样，可以使用dir参数来进行修改，aof的默认文件名是appendonly.aof 。
aof有下面三种持久化的机制：
appendfsync always # 每执行一次修改数据的命令，就写入aof文件，这种做法会严重影响redis的性能
appendfsync everysec # 每秒钟同步一次，将多次写操作同步到硬盘中
appendfsync no # 让操作系统决定何时同步
为了兼顾数据和性能，一般都选择appendfsync everysec ，让redis每秒同步一次aof文件，这样不会影响到redis的速度；而且就算系统发生故障，用户最多就丢失一秒内所产生的数据。
1、redis4.0对持久化的优化
redis4.0后开始支持RDB和AOF的混合持久化，默认不开启，可以使用aof-use-rdb-premble 参数进行开启。
如果把混合持久化开启，AOF重写的时候就直接把RDB写入AOF文件的开头 ，这样做的话可以结合RDB和AOF的优点，快速加载同时避免丢失过多的数据 。但是这样做也有缺点，就是AOF文件里面的RDB部分是压缩格式而不是AOF格式，可读性差 。
2、关于AOF重写
AOF重写会生成一个新的AOF文件，新AOF文件与旧AOF文件保存的数据库状态一致，但是文件体积更小。AOF重写是一个比较有歧义的名字，因为AOF重写是通过读取数据库的键值对来完成的，程序不需要对原有的AOF文件进行任何的读取、分析、写入操作。
3、AOF重写过程
当执行BGETWRITEAOF命令时，Redis服务器会维护一个AOF重写缓冲区，该缓冲区会在子进程生成新的AOF文件期间，记录服务器的所有写操作。等到子进程完成新的AOF文件生成后，会将AOF重写缓冲区的内容追加到新的AOF文件的末尾，使得新旧AOF文件保存的数据库的状态一致。然后服务器将新的AOF文件覆盖旧的AOF文件，以此就完成了重写的操作。