redis持久化机制

持久化机制就是将内存中的数据写到磁盘中，防止服务宕机造成数据丢失。

redis提供两种对数据进行持久化存储的机制。

RDB方式

redis默认的持久化方案。

在指定的时间间隔内将内存中的数据集快照写入磁盘的一个dump.rdb文件，数据恢复时将快照文件直接再读到内存。

触发RDB持久化的方式

1、手动触发

SAVE命令：会阻塞所有客户端的请求，避免在生产环境使用

BGSAVE命令：可以在后台异步进行快照操作，服务器还可以继续响应客户端的请求。手动触发推荐该命令。

执行过程：父进程先判断是否存在子进程，如果没有则父进程执行 fork 操作创建子进程，父进程继续接受处理客户端的数据，子进程将内存中的数据写入磁盘中的临时文件，写完数据后替换旧的RDB文件。

2、自动触发

redis.conf 配置文件进行配置，配置格式：save <seconds N> <changes M>

即在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。但是同时使用会影响性能。