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

对于错误格式的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资源的进程。