持久化机制就是将内存中的数据写到磁盘中,防止服务宕机造成数据丢失。
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。但是同时使用会影响性能。