一文了解Redis的持久化( 二 )


所以按照使用来说,更多的人会选择 RDB 的持久化 。
写入操作Redis 在收到客户端修改命令后,先进行相应的校验 , 如果没问题,就立即将该命令存追加到 .aof 文件中,也就是先存到磁盘中,然后服务器再执行命令 。这样就算遇到了突发的宕机情况情况 , 也只需将存储到 .aof 文件中的命令,进行一次“命令重演”就可以恢复到宕机前的状态 。
也就是说,他是先存磁盘,然后再去执行命令 。
而 Redis 为了提升写入效率 , 它不会将内容直接写入到磁盘中,而是将其放到一个内存缓存区(buffer)中等到缓存区被填满时采用异步真正将缓存区中的内容写入到磁盘里 。
所以就有了问题,如果机器突然宕机,AOF 日志内容可能还没有来得及完全刷到磁盘中,这个时候就会出现日志丢失 。
我们都能知道这么浅显的问题,那么 Redis 一定是可以解决的,解决方案都很粗暴,直接就是配置文件上写明了 。

一文了解Redis的持久化

文章插图
图片
  • Everysec默认
服务器每一秒调用一次 fsync 函数,将缓冲区里面的命令写入到硬盘 。这种模式下,服务器出现故障,最多只丢失一秒钟内的执行的命令数据,通常都使用它作为 AOF 配置策略
  • Always
服务器每写入一个命令,就调用一次 fsync函数,将缓冲区里面的命令写入到硬盘 。这种模式下,服务器出现故障 , 也不会丢失任何已经成功执行的命令数据,但是其执行速度较慢
  • No
服务器不主动调用 fsync 函数,由操作系统决定何时将缓冲区里面的命令写入到硬盘 。这种模式下,服务器遭遇意外停机时 , 丢失命令的数量是不确定的,所以这种策略,不确定性较大,不安全 。
而我们如果选用了 AOF ,那么在生产环境的服务器中,Redis 通常是每隔 1s 左右执行一次 fsync 操作( Everysec) , 这样既保持了高性能,也让数据尽可能的少丢失 。
AOF 配置开启AOF默认不开启,可以在 redis.conf 文件中对AOF进行配置开启:
appendonly no # 是否开启AOF,yes:开启,no:不开启,默认为noappendfilename "appendonly.aof" # aof文件名称,默认为appendonly.aofdir ./ # aof文件所在目录,默认./ , 表示执行启动命令时所在的目录AOF 的备份恢复
AOF的备份机制和性能虽然和RDB不同,但是备份和恢复的操作同RDB一样,都是拷贝备份文件,需要恢复时再拷贝到Redis工作目录下,启动系统即加载 。
所以关于 Redis 的持久化操作,你学会了么?

【一文了解Redis的持久化】


推荐阅读