redis作为内存存储系统,数据都保存在内存中,当服务器断电之后数据都会丢失,为了能恢复数据,redis准备了AOF(Append only file).
AOF是写后日志,在执行完redis的操作命令之后,会把操作记录追加到日志文件中。
redis写命令:put aaa:123432
在执行完当前命令之后,会把put aaa:123432这条命令追加到日志文件中,这个就是AOF机制。
- Mysql:WAL
mysql 又一个WAL机制非常类似,Write ahead logging,在引擎中会追加结果集日志到redolog;而且还有两阶段提交,保证日志的完整性
- Redis: AOF
redis的AOF是写后日志,追加的是逻辑记录。所以一个AOF日志里面,存储的都是操作记录,可以在redis重启之后,逐条执行恢复数据。
AOF的写入策略:appendfsync属性
- always:每次写入:每次操作之后都写入文件,优点:不丢失数据,缺点:影响性能。
- everysec:每秒写入:每次操作之后不写入文件,只把操作记录写入缓冲区,每一秒一次缓冲区写入文件系统。优点:影响性能不大,缺点:可能会丢失1秒内的操作记录。
- no:不写入:当缓冲区满了,操作系统自己决定写入文件系统,优点:不影响性能,缺点:可能会丢失很多操作记录。
建议选择everysec 这种模式
AOF优点:
- 可以保证执行正确的操作才被记录在AOF中
- 保存的是逻辑操作命令,可以逐条执行恢复
AOF缺点:
- 因为命令执行是单线程,同步操作文件系统是耗时操作
- 文件追加太多,文件系统过大,速度变慢
- redis重启之后,逐条执行,速度缓慢
AOF改进:
- AOF重写机制,当文件过大时,为了去重操作,比如对aaa这个key的多次操作。可以逐条读取存储内容,然后只写一条写入命令到AOF重写文件。
- 在重写期间,主线程fork子线程(bgrewriteaof)执行AOF重写。这样就不会耽误主线程继续接受请求。而且bgrewirteaof会获取主线程的内存副本,即redis存储数据copy文件。
- “两处日志”,在主线程执行操作命令的时候,操作日志会写入AOF日志,也会写入AOF重写日志,这样就保证AOF保存了全量的操作日志