述
上文中说了快照持久化,那本文再来看一下另外一种持久化的方式,就是AOF(append-only file)
AOF持久化
AOF持久化是把被执行的命令都写到一个aof文件末尾,在恢复的时候只需要从头到尾执行一遍写命令即可恢复数据.
AOF在redis中默认是没有开启的,需要手动配置开启
相关配置
开启AOF持久化,需要在redis.conf中,找到 appendonly这个配置,修改为yes,如下:1
appendonly yes
还有几个AOF相关的配置,如下:1
2
3
4
5
6
7appendfilename "appendonly.aof"
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
这些配置的作用如下:
- appendfilename: 表示生成的AOF文件的名称
- appendfsync: 表示备份的时机,always是每执行一个命令就备份一次,everysec表示每秒备份一次, no表示将备份时机交给操作系统
- no-appendfsync-on-rewrite: 表示在对aof文件进行压缩时，是否执行同步操作
appendfsync 备份时机的设置
如上面所说,appendfsync一共可以设置三种,我们在实际使用中,首选是everysec,也就是每秒钟备份一次
如果设置always,会严重影响redis的性能,如果设置everysec,最坏的情况也就是会丢失一秒钟的数据
AOF文件的重写与压缩
如果我们开启了AOF备份的话,随着系统的运行,AOF文件会越来越大,甚至会把电脑的磁盘跑满, AOF文件的重写与压缩机制可以在一定程度上缓解这个问题
当AOF的备份文件过大的时候,我们可以向redis发送一条bgrewriteaof命令,进行文件重写,如下:1
2172.16.12.3:6379> bgrewriteaof
Background append only file rewriting started
bgrewriteaof的执行原理和我们上文说的bgsave的原理一致,这里我就不再赘述,因此bgsave执行过程中存在的问题在这里也一样存在
bgrewriteaof也可以自动执行,依赖于相关配置中的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置
auto-aof-rewrite-percentage 100: 表示当目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时会再次进行重写auto-aof-rewrite-min-size 64mb:表示如果之前没有重写,则以启动时的AOF文件大小为依据,同时还要求AOF文件的大小至少要大于64M
对比
两种持久化的方式就先介绍到这里, 下面将快照持久化(RDB)和AOF持久化做一个比较
| 命令 | RDB | AOF |
|---|---|---|
| 启动优先级 | 低 | 高 |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 丢数据 | 根据策略决定 |
| 轻重 | 重 | 轻 |
最佳策略
首先,如果reids是只做缓存服务器的话,可以不开启任何持久化
如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失,那么你可以只使用 RDB 持久
AOF将Redis执行的每一条命令追加到磁盘中,处理巨大的写入会降低Redis的性能,不知道你是否可以接受
定时生成 RDB 快照(snapshot)非常便于进行数据库备份,并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快
Redis 支持同时开启 RDB 和 AOF,系统重启后,Redis 会优先使用 AOF 来恢复数据,这样丢失的数据会最少.