Redis-AOF持久化

Redis持久化-AOF

一. AOF持久化原理

 AOF(append only file)持久化是以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF主要作用是解决了数据持久化的实时性,目前已经是redis持久化的主流方式。

二. 开启AOF持久化

(1)开启AOF持久化,需要设置appendonly参数的值为yes,默认不开启。

(2)aof文件名通过appendfilename配置设置,默认文件名为appendonly.aof

(3)aof文件保存路径通过dir参数来指定。

 

redis.conf中的相关配置如下:

appendonly yes(此处需修改为yes,启用aof,默认为no)

appendfilename "appendonly.aof"

dir "/home/devuser/software/redis/redis-3.2.4/redis_instance/8001"

 

三 AOF的工作流程

3.1 工作流程

(1)      所有写命令会被追加aof_buf(缓冲区)中

(2)      AOF缓冲区根据对应的策略向硬盘做同步操作

(3)      随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的

(4)      当 redis服务器进行重启时,可以加在AOF文件进行数据恢复

3.2 命令写入

(1)AOF命令写入的内容直接是文本协议格式,因为该协议具有很好的兼容性,可读性,方便直接修改和处理。开启AOF后,所有写入命令都包含追加操作,直接采用协议格式避免了二次处理的开销。

(2)命令写入只是将命令追加到AOF缓冲区中,因为redis是采用单线程响应命令,如果每次写AOF命令都直接追加到硬盘,那么性能完全取决于当前硬盘的负载。先写入AOF缓冲区中还有另一个好处,redis可以提供多种缓冲区同步硬盘的策略,在性能和安全性方面作曲权衡。

3.3 文件同步

3.3.1 AOF缓冲区同步文件策略

Redis提供了多种AOF缓冲区同步文件策略,由参数appendfsync控制。

apendfsync参数的选项如下:

always:命令写入AOF缓冲区后调用系统fsync操作同步到AOF文件中,fsync完成后线程返回

everysec(默认配置):命令写入AOF缓冲区后调用系统write操作,write完成后线程返回。fsync同步文件操作由专门线程每秒调用一次。Everysec是建议的同步策略。理论上只有在系统突然宕机的情况下丢失1秒的数据。

no:命令写入AOF缓冲区后调用系统write操作,write完成后线程后线程返回,不对AOF文件作fsync同步,同步硬盘操作由操作系统负责,通常同步周期最长30秒。

 

3.3.2 系统调用write和fsync说明

(1)write

Wirte操作会触发延迟写机制。在写入系统缓冲区后直接返回,同步硬盘操作依赖于系统调度机制。同步硬盘之前,如果系统故障宕机,缓冲区内的数据将丢失。

(2)fsync

Fsync针对单个文件操作(比如AOF文件),做强制硬盘同步,fsync将阻塞直到写入硬盘完成后返回,保证了数据持久化。

3.4 文件重写

3.4.1 AOF文件重写的作用

随着命令的不断写入,AOF文件越来越大。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。更小的AOF文件降低了文件占用空间,也可以更快的被redis加载。

3.4.2 AOF文件重写后变小的原因

1)  进程内已经超时的数据不再写入文件

2)  旧的AOF文件中含有无效的命令,如seta111,重写使用进程内数据直接生成,这样新的AOF文件只保留最终数据写入命令。

3)  多条写命令可以合并为1个,如:lpushlist a、lpush list b可以合并为lpush list a b,为防止单条命令过大造成客户端缓冲区溢出,对于list,set,zset,hash等操作,以64个元素为界拆分为多条。

3.4.3 AOF重写触发方式
3.4.3.1 手动触发

直接调用bgrewriteaof命令

3.4.3.2 自动触发

根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。

auto-aof-rewrite-min-size:表示运行AOF重写时aof文件的最小体积。默认为64MB。

auto-aof-rewrite-percentage:代表当前AOF文件空间(aof_current_size)和上一次重写后AOF文件空间(aof_base_size)的比值

自动触发时机=aof_current_size>auto-aof-rewrite-min-size&&(aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage

Reids.conf中的默认设置:

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

 

aof_current_size和aof_base_size可以通过infopersistence

10.3.34.101:6378> info persistence

# Persistence

loading:0

rdb_changes_since_last_save:3

rdb_bgsave_in_progress:0

rdb_last_save_time:1500430990

rdb_last_bgsave_status:ok

rdb_last_bgsave_time_sec:0

rdb_current_bgsave_time_sec:-1

aof_enabled:1

aof_rewrite_in_progress:0

aof_rewrite_scheduled:0

aof_last_rewrite_time_sec:0

aof_current_rewrite_time_sec:-1

aof_last_bgrewrite_status:ok

aof_last_write_status:ok

aof_current_size:924

aof_base_size:817

aof_pending_rewrite:0

aof_buffer_length:0

aof_rewrite_buffer_length:0

aof_pending_bio_fsync:0

aof_delayed_fsync:0

3.4.4 AOF重写工作流程

(1)      执行AOF重写请求

a.      如果当前进程正在执行AOF重写,当前请求不执行,并返回如下响应:

ErrorBackground append only file rewriting already in progress

b.      如果当前进程正在执行bgsave操作,重写命令延迟到bgsave操作结束后再执行,并返回如下响应:

Background append only file rewriting scheduled

(2)      父进程执行fork操作创建子进程,fork操作执行过程中,redis父进程会阻塞。

(3)      主进程fork操作完成后,继续响应其他命令。所有修改命令继续写入AOF缓冲区(AOF_BUF)并根据appendfsync策略同步到硬盘,保证原有AOF机制的正确性。

(4)      由于fork操作运用写时复制技术,子进程只能共享fork操作时的内存数据。由于父进程依然响应命令,Redis使用“AOF重写缓冲区”保存这部分数据,防止新AOF文件生成期间丢失这部分数据。

(5)      子进程根据内存快照,按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数量由配置aof-rewrite-incremental-fsync控制,默认为32MB,防止单次刷盘数据过多造成阻塞。

(6)      新AOF文件写入完成后,子进程发送信号给父进程,父进程更新统计信息

(7)      父进程将AOF重写缓冲区的数据写入到新的AOF文件

(8)      使用新的AOF文件替换老文件,完成AOF重写。

3.5 重启加载

AOF和RDB都可以用于服务器重启时的数据恢复。下图表示Redis持久化文件的加载流程。

流程说明:
1. AOF持久化开启且存在AOF文件时,优先加载AOF文件,打印如下日志:
*DB loaded from append only file: 5.841 seconds
2.AOF关闭或者AOF文件不存在时,加载RDB文件,打印如下日志:
   * DB loaded from disk:5.586seconds
3. 加载AOF/RDB文件存在错误,Redis启动失败并打印错误信息


3.6 文件校验

加载损坏的AOF文件时会拒绝启动,并打印如下日志:

# Bad file format reading the append onlyfile:make a backup of your AOF file.then user ./redis-check-aof–fix<filename>

对于错误格式的AOF文件,先进行备份,然后采用redis-check-aof–fix命令进行修复,修复后使用diff –u对比数据差异,找出丢失的数据,有些可以人工修改补全。

AOF文件可能存在结尾不完整的情况,比如机器突然掉电导致AOF尾部文件命令写入不全。Redis为我们提供了aof-load-truncated配置来兼容这种情况,默认开启。加载AOF时,当遇到此问题时会忽略并继续启动,同时打印如下警告日志;

#!!! Warningshort read while looading the AOF file !!!

#!!! Truncatingthe AOF at offset 397856725 !!!

#!!! AOF loadedanyway because aof-load-truncated is enabled

四, 问题定位与优化

4.1 fork操作

Fork操作会阻塞redis进程,对于高流量的redis实例ops可达5万以上,如果fork操作耗时在秒级别将拖慢Redis几万条命令执行。正常情况下fork耗时应该是每GB消耗20毫秒左右。可以在info stats统计中查看latest_fork_usec指标获取最近一次fork操作耗时,单位微秒。

如何改善fork操作的耗时:

(1)      优先使用物理机或者高效支持fork操作的虚拟化技术,避免使用Xen。

(2)      控制Redis实例最大可用内存,fork耗时跟内存量成正比,线上建议每个Redis实例内存控制在10GB以内。

(3)      合理配置Linux内存分配策略,避免物理内存不足导致fork失败。

(4)      降低fork操作的频率,如适度放宽AOF自动触发时机,避免不必要的全量复制等。

4.2 子进程开销监控和优化

4.2.1 CPU

Redis属于CPU密集型操作,通常子进程对单核CPU利用率接近90%。

(1)      不要绑定单核CPU操作。由于子进程非常消耗CPU,会和父进程产生单核资源竞争。

(2)      不要和其他CPU密集型服务部署在一起,造成CPU过渡竞争

(3)      如果部署多个REDIS实例,尽量保证同一时间只有一个子进程执行重写工作。

4.2.2 内存

子进程通过fork操作产生,占用内存大小等同于父进程,理论上需要两倍内存来完成持久化操作,但Linux有写时复制机制。父子进程会共享相同的物理内存页,当父进程处理写请求时会把要修改的页创建副本,而子进程在fork操作过程中共享整个父进程内存快照。

(1)      如果部署多个Redis实例,尽量保证同一时刻只有一个子进程在工作。

(2)      避免大量写入时做子进程重写操作,这样将导致父进程维护大量页副本,造成内存消耗

(3)      Linux kernel在2.6.38内核增加了TransarentHuge Pages(THP)。支持huge page(2MB)的页分配,默认开启。当开启时可以降低fork创建子进程的速度,但执行fork后,如果开启THP,复制单位从原来的4KB变为2MB,会大幅增加重写期间父进程内存消耗,建议设置“sudo echo never>/sys/kernel/mm/transparent_hugepage/enabled“,关闭THP。

4.2.3 硬盘

子进程主要职责是将AOF或者RDB文件写入磁盘持久化。势必造成硬盘写入压力。根据Redis重写AOF/RDB的数据量,结合系统工具如sar、iostat、iotop等,可分析出重写期间硬盘负载情况。

硬盘开销优化方法:

(1)      不要和其他高硬盘负载的服务部署在一起,如:存储服务、消息队列服务等

(2)      AOF重写时会消耗大量硬盘IO,可以开启配置no-appendfsync-on-rewrtie,默认关闭。表示在AOF重写期间不做fsync操作。如果配置,有可能丢失整个AOF重写期间的数据,需要根据数据安全性决定是否配置。

(3)      当开启AOF功能的redis用于高流量写入场景时,如果使用普通机械磁盘,写入吞吐一般在100MB/S左右,这时Redis实例的瓶颈主要在AOF同步硬盘上。

(4)      对于单机配置多个Redis实例的情况,可以配置不同实例分盘存储AOF文件,分摊磁盘写入压力

4.3 AOF追加阻塞


阻塞流程分析:

(1)      主线程负责写入AOF缓冲区

(2)      AOF线程负责每秒执行一次同步磁盘操作,并记录最近一次同步时间

(3)      主线程负责对比上次AOF同步时间

a.      如果距上次同步成功时间在2秒内,主线程直接返回。

b.      如果距上次同步成功时间超过2秒,主线程将会阻塞,直到同步操作完成。

通过对AOF阻塞流程可以发现两个问题:

a.      everysec配置最多可能丢失2秒数据,不是1秒

b.      如果系统fsync缓慢,将会导致Redis主线程阻塞影响效率

    AOF阻塞问题定位:

(1)      发生AOF阻塞时,Redis输出如下日志,:

Asynchronous AOF fsync is taking toolong(disk is busy). Wrting the AOF buffer without waiting for fsync tocomplete,this may slow down Redis

(2)      每当发生AOF追加阻塞事件发生时,在info persistence统计中,aof_delayed_fsync指标会累加,查看这个指标方便定位AOF阻塞问题

AOF同步最多允许2秒的延迟,当延迟发生时,说明硬盘存在高负责问题,可以通过监控工具如iotop,定位消耗硬盘IO资源的进程。
展开阅读全文

没有更多推荐了,返回首页