aof原理:
来看一看aof的配置:
这是是否开启aof功能的开关
这是aof工作的三种方式:
#每一个命令都立即同步到aof,安全但是速度慢
#折衷方案,每秒写一次
#写入工作交给操作系统,有操作系统判断缓冲区大小统一写到aof,同步频率低,速度快。
#正在导出rdb快照的过程中要不要停止同步aof
#aof文件大小比起上次重写时的大小,增长率%100时重写。
#aof文件,至少超过64m时重写。
注意:在dumprdb过程中,aof如果停止同步,会不会丢失?
答:不会,所有的操作缓存在内存的队列里,dump完成后统一操作。
注意:aof重写是指什么?
答:aof重写是指把内存中的数据,逆化成命令,写入到aof日志里。以解决aof文件过大的问题
问:如果rdb和aof文件都在,优先使用哪个恢复数据?
答:aof
问:2种是否可以同时用?
答:可以,而且推荐这么做。
问:恢复时哪个恢复速度快?
答:rdb快,因为是数据的内存映射,直接载入到内存,而aof需要逐条执行。
下面看执行:
执行两条语句看
生成了aof文件且生成了日志。
对了aof还有个问题,就是你对同一个key操作一百次,可能这个key只是数值增加了一百次,对内存来说这个key占的内存并不多,但是写到aof文件中就是多了一百条命令,这里就出现两个后果:
1.造成aof文件过大
2.恢复的时候也太繁琐,慢。
看例子:
怎么解决呢?
在某个时间点将key/value逆化成一个命令,这就是aof重写。aof每次重写都会使aof的容量减小。重写的配置见上文。
测试可以通过redis-benchmark -n num 来测试,在测试的同时实时查看aof文件的大小,当达到64m的时候文件大小会骤减。
当然也可以通过命令bgrewriteaof命令重写(这就不会存在命令冗余了)。这涉及到redis的运维。