redis-AOF

一.AOF概述

• 使用日志功能保存数据的操作
• 默认AOF机制关闭的
• 适用于内存比较小的计算机,但是对于大公司来说不存在内存小的问题,所以对于大公司比起AOF,它们都是选择默认的RDB

二.AOF优势

1. 该机制可以带来更高的数据安全性,即数据持久性。Redis中提供了3种同步策略,即每秒同步,每修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会被立即记录都磁盘中。可以预见,这种方式在效率上是最低的。至于无同步,无需多言,我想大家都能正确的理解它。
2. 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题
3. 如果日志过大,redis可以自动启动rewrite机制,即redis以append模式不断的将修改数据写入到老的磁盘文件中,同时redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行了。因此在进行rewrite切换时可以更好的保证数据安全性
4. AOF包含一个格式清晰,易于理解的日志文件用于记录所又的修改操作。事实上,我们也可以通过该文件完成数据的重建

三.AOF劣势

1. 对于相同数量的数据集而言,AOF文件通常用大于RDB文件
2. 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效

四.AOF配置信息

always    #每次有数据修改发生时都会写入AOF文件
everysec   #每秒钟同步一次,该策略为AOF的缺省策略
no        #从不同步。高效但是数据不会被持久化

• 重写AOF:若不满足重写条件时,可以手动重写,命令:bgrewriteaof

每秒同步(默认):每秒进行一次AOF保存数据。 安全性低,比较节省系统资源
每修改同步:只要有key变化语句,就进行AOF保存数据。比较安全,但是极为浪费效率
不同步:不进行任何持久化操作  不安全
我们要选择就选择每修改同步

五.AOF配置

• 因为AOF默认是关闭的,想开启要修改redis.conf配置文件

把默认的no改为yes,开启AOF配置

把默认的每秒改为每修改,然后保存

我们先关掉服务器,删掉dump.rdb文件,再启动

因为你删掉了dump.rdb文件,所以没得数据

我们再执行以下的语句

我们关闭掉redis,然后查看多了一个appendonly.aof文件,我们来查看它的内容

只存在着修改key的语句

总结

• 优点
  
  • 持续性占用极少量的内存资源
  • AOF日志程序—KB而已
• 缺点
  
  • 日志文件会特别大,不适用于灾难备份(一个数据可能有多条数据变过来的)
  • 恢复效率远远低于RDB