AOF
记录日志是在处理完请求时,好处是记录的都是成功的请求,不会阻塞写操作 但是会阻塞后续的操作,因为这一步也是主线程执行的
写入磁盘是影响性能的,redis给我们提供了三种同步时机
1. always
2. everysec
4. no 先写入aof文件的内存缓冲区 由系统决定何时存入磁盘
当aof文件过大的时候可以AOF重写,不是去读就的aof日志而是父子线程同时指向相同的内存地址,
新的aof日志当重写期间有新的数据操作会把数据写入重写缓冲区,等重写完再追加缓冲区中的命令
父进程采用写时复制,在有操作一个数据的时候才会复制对应的内存页,映射到新的物理地址并写入,一读一写会造成读写放大,并且更高的内存页大小
会放大读写的效率,对redis性能产生影响
注意: 重写是不阻塞的会起一个后台线程执行
那么在aof重写的时候会产生阻塞吗?
主线程fork子线程去重写的时候会产生阻塞,fork子线程时需要拷贝必要的数据到子线程工作内存,其中一项就是拷贝内存页表这个拷贝过程会消耗大量的cpu时间
这个内存页表就是虚拟内存与物理内存的映射索引表,拷贝的时间消耗取决于实例的大小
在主线程修改存在的数据时 才会去复制对应的内存页数据,需要开辟新的内存空间
所以 如果主线程申请的是一个bigkey就需要开辟很大的内存空间耗时过长造成主内存堵塞
如果操作系统开启了huge page会加剧主内存的拷贝效率 因为内存页变大 主内存拷贝的数据量就响应的变大内存的读取单位是内存页
重写aof为什么不跟主线程用同一个aof日志呢?
可能会产生重写失败的情况,使得原先的aof日志被污染
重写线程和主线程产生竞争影响主线程效率