持久化机制就是将内存中的数据写到磁盘中，防止服务宕机造成数据丢失。
redis提供两种对数据进行持久化存储的机制。
RDB方式
redis默认的持久化方案。
在指定的时间间隔内将内存中的数据集快照写入磁盘的一个dump.rdb文件，数据恢复时将快照文件直接再读到内存。
触发RDB持久化的方式
1、手动触发
SAVE命令：会阻塞所有客户端的请求，避免在生产环境使用
BGSAVE命令：可以在后台异步进行快照操作，服务器还可以继续响应客户端的请求。手动触发推荐该命令。
执行过程：父进程先判断是否存在子进程，如果没有则父进程执行 fork 操作创建子进程，父进程继续接受处理客户端的数据，子进程将内存中的数据写入磁盘中的临时文件，写完数据后替换旧的RDB文件。
2、自动触发
redis.conf 配置文件进行配置，配置格式：save
即在N秒内至少M个key被修改则自动保存一次数据集。
优点：1、恢复数据的速度远快于AOF方式
2、使用单独的子进程来进程持久化，主线程不会进行任何IO操作，保证了redis的高性能。
缺点：1、如果redis异常退出，会丢失最近一次持久化以后更改的数据。如果应用容忍一定数据的丢失，使用RDB方式是个不错的选择。也可以选择适当的保存策略来降低数据丢失的风险。
2、BGSAVE每次运行时都要执行fork操作创建子进程，属于重量级操作，频繁执行成本较高。
3、存在老版本redis无法兼容新版RDB格式的问题。
AOF方式
redis每次接收到一条改变数据的命令时，它会将命令写到一个AOF文件中，只记录写操作，不记录读操作。redis重启时，通过执行AOF文件中的所有命令来恢复数据。主要作用就是解决了数据持久化的实时性。AOF现在是redis持久化的主流方式。
AOF默认情况下是没有开启的，需要修改redis.conf配置文件的appendonly参数为yes。默认文件名为appendonly.aof。
appendfsync参数：配置向aof文件写命令数据的策略。
appendfsync : no 不进行同步操作，而是完全交由操作系统来做，30秒一次同步。
appendfsync : always 每次执行写入都会执行同步，比较安全
appendfsync : everysec 每秒执行一次同步操作，默认项
AOF持久化执行流程：
1、所有的写入命令会追加到AOF缓冲区中。
2、AOF缓冲区根据对应的策略向硬盘同步。
3、AOF文件大于一定值时，默认是64M，开始整理aof文件，即进行重写，去掉无用的操作命令。达到压缩文件的目的。
4、redis服务器重启时，可以加载aof文件进行数据恢复。
优点：1、AOF可以更好的保护数据不丢失。
2、以appendonly模式写入，没有磁盘寻址的开销，写入性能非常高。
缺点：1、对于同一份文件AOF文件比RDB数据快照大。
2、AOF数据恢复较慢。
总结：
1、如果项目中数据是第一位的，使用AOF更安全。
2、两种是可以同时使用的，先读AOF，再读RDB。但是同时使用会影响性能。
