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资源的进程。

知识小贴士：作者尽心运营的知识星球社群【请点击：简道源码&&架构分析 加入】（可添加运营同学WX：wx454876882）持续拉新中...，定期的jdk与核心框架源码解析，主流行业解决方案与架构设计资料查阅与下载尽在其中。帮助行业新人和有志于技术的专业人士体系化的学习源码与系统架构，获取业界知名技术峰会和厂商对外公布的主流业务场景的解决方案。同时这个星球也是一个社群，大家可以在社群中结识有识之士，共同探讨，答疑解惑。希望可以通过这个星球帮助大家每日进步一点点，一年持续365天，共勉~

本星球 聚焦于Java源码分析，架构解析。低代码，可扩展和高可用架构设计。帮助你更好地学编程，欢迎想进步的同学！仅精品案例的资料整理即物超所值。让我们大家一起每日进步一点点~，你可以：

1. 阅读星球专属的编程知识和优质文章

2.JAVA知识从点和面，深度挖掘。通过点，形成面。提升自身的技术广度和深度。

3. 加入星球专属交流群，帮你找到学习伙伴、获取每日优质文章推送等

4.业界优秀案例资料学习及下载

5. 和伙伴们一起学习打卡，增加动力，共同进步

6.工作、学习和方法论。如何提升软实力，比如写文章、画架构图、技术产品的营销、社区的运营等等。

7.招聘、面试和晋升。如何提前准备面试，有什么套路？如何提升硬实力，少走弯路？

8.提供简历优化服务哟。本人常年招聘，也就面试了1000+程序员和架构师~~

9.解答你的疑问。

10.每日进步一点点(最重要的一点): 让自己与众不同，每天学习1-2小时源码和架构知识，365天后再回首，1年前的自己可能是个SB吧。用通勤的时间让自己成长，让优秀变成一种习惯。