Redis数据持久化机制比较及问题

一、两者比较

RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

1.性能：Snapshot方式的性能是要明显高于AOF方式的，原因有两点：

1）采用二进制方式存储数据，数据文件比较小，加载快速.

2）存储的时候是按照配置中的save策略来存储，每次都是聚合很多数据批量存储，写入的效率很好，而AOF则一般都是工作在实时存储或者准实时模式下。相对来说存储的频率高，效率却偏低。

3) 对于redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

2.数据安全：AOF数据安全性高于Snapshot存储，原因：

Snapshot存储是基于累计批量的思想，也就是说在允许的情况下，累计的数据越多那么写入效率也就越高，但数据的累计是靠时间的积累完成的，那么如果在长时间数据不写入RDB，但Redis又遇到了崩溃，那么没有写入的数据就无法恢复了，但是AOF方式偏偏相反，根据AOF配置的存储频率的策略可以做到最少的数据丢失和较高的数据恢复能力。

RDB优势：

1). 备份策略方便：一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

2). 灾难恢复方便：，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化：对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4). 启动效率高：相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB缺点：

1). 数据的可靠性不高，没办法做到实时持久化：如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2). 影响性能：由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

3）版本兼容RDB格式问题

AOF的优点：

1). 数据安全性：该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。

2). 数据一致性：由于该机制对日志文件的写入操作采用的是Append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的缺点：

1). 恢复速度慢：对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2). 性能低：根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

二、Redis持久化磁盘IO方式及其带来的问题

1、RDB持久化可能导致系统内存不足导致redis 被 oom kill

发现Redis在物理内存使用比较多，但还没有超过实际物理内存总容量时就会发生不稳定甚至崩溃的问题。

redis持久化AOF重写和RDB写入都是通过fork产生子进程来操作，AOF重写和RDB写入都是通过fork产生子进程来操作，理论上需要两倍的内存来完成持久化操作，但linux有写时复制机制（copy-on-write），父子进程会共享相同的物理内存页（只有有写入的脏页会被复制）， 当父进程处理写请求时会把要修改的页创建副本，而子进程在fork操作过程中共享整个父进程内存快照。避免在大量写入时做子进程重写操作，这样将导致父进程维护大量页副本，造成内存消耗。

但是由于Redis的持久化使用了Buffer IO，所谓Buffer IO是指Redis对持久化文件的写入和读取操作都会使用物理内存的Page Cache, 而大多数数据库系统会使用Direct IO来绕过这层Page Cache并自行维护一个数据的Cache，而当Redis的持久化文件过大(尤其是快照RDB文件)，并对其进行读写时，磁盘文件中的数据都会被加载到物理内存中作为操作系统对该文件的一层Cache,而这层Cache的数据与Redis内存中管理的数据实际是重复存储的，虽然内核在物理内存紧张时会做Page Cache的剔除工作，但内核很可能认为某块Page Cache更重要，而让你的进程开始Swap ,这时你的系统就会开始出现不稳定或者崩溃了。我们的经验是当你的Redis物理内存使用超过内存总容量的3/5时就会开始比较危险了。

下图是Redis在读取或者写入快照文件dump.rdb后的内存数据图：

2、持久化Fork引起redis主进程阻塞

AOF重写和RDB写入都是通过fork产生子进程来操作，子进程占用内存大小等同于父进程，理论上需要两倍的内存来完成持久化操作，但Linux有写时复制机制（copy-on-write）。父子进程会共享相同的物理内存页，当父进程处理写请求时会把要修改的页创建副本，而子进程在fork操作过程中共享整个父进程内存快照。避免在大量写入时做子进程重写操作，这样将导致父进程维护大量页副本，造成内存消耗。

测试把benchmark的11G数据写成一个1.3的RDB文件，或者等大的AOF文件rewrite，需要80秒，在redis-cli info中可查看。启动时载入一个AOF或RDB文件的速度与上面写入时相同，在log中可查看。

Fork一个使用了大量内存的进程也要时间，大约10ms per GB的样子，但Xen在EC2上是让人郁闷的239ms (KVM和VMWare貌似没有这个毛病)，各种系统的对比，Info指令里的latest_fork_usec显示上次花费的时间。

3、在AOF持久化重写时，AOF重写缓冲区的指令追加新文件和改名替换造成阻塞：

在AOF持久化过程中，所有新来的写入请求依然会被写入旧的AOF文件，同时放到buffer中，当rewrite完成后，会在主线程把这部分内容合并到临时文件中之后才rename成新的AOF文件，所以rewrite过程中会不断打印”Background AOF buffer size: xx MB， Background AOF buffer size: xxMB”，这个合并的过程是阻塞的，如果你产生了280MB的buffer，在100MB/s的传统硬盘 上，Redis就要阻塞2.8秒！！！

4、持久化的系统IO阻塞redis主进程的问题

持久化很容易造成阻塞，不管是AOF rewrite，还是RDB bgsave，都有可能会出现阻塞，原因是一般情况下，如果Redis服务设置了appendfsync everysec, 主进程每秒钟便会调用fsync, 将数据写到存储磁盘里. 但由于服务器的重写子进程正在进行大量IO操作, 导致主进程fsync/操作被阻塞, 最终导致Redis主进程阻塞.解决方案这里就不多说了

5、Redis持久化性能调整

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

如果启用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值，比如之前的 benchmark每个小时会产生40G大小的AOF文件，如果硬盘能撑到半夜系统闲时才用cron调度bgaofrewrite就好了。

如 果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启 动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构，见Tim的博客

三、 实际问题

1、Trouble Shooting —— Enable AOF可能导致整个Redis被Block住，在2.6.12版之前

现象描述：当AOF rewrite 15G大小的内存时，Redis整个死掉的样子，所有指令甚至包括slave发到master的ping，redis-cli info都不能被执行。

原因分析：

官方文档，由IO产生的Latency详细分析, 已经预言了悲剧的发生，但一开始没留意。

Redis为求简单，采用了单请求处理线程结构。

打开AOF持久化功能后， Redis处理完每个事件后会调用write(2)将变化写入kernel的buffer，如果此时write(2)被阻塞，Redis就不能处理下一个事件。

Linux规定执行write(2)时，如果对同一个文件正在执行fdatasync(2)将kernel buffer写入物理磁盘，或者有system wide sync在执行，write(2)会被block住，整个Redis被block住。

如 果系统IO繁忙，比如有别的应用在写盘，或者Redis自己在AOF rewrite或RDB snapshot(虽然此时写入的是另一个临时文件，虽然各自都在连续写，但两个文件间的切换使得磁盘磁头的寻道时间加长），就可能导致 fdatasync(2)迟迟未能完成从而block住write(2)，block住整个Redis。

为了更清晰的看到fdatasync(2)的执行时长，可以使用”strace -p (pid of redis server) -T -e -f trace=fdatasync”，但会影响系统性能。

Redis 提供了一个自救的方式，当发现文件有在执行fdatasync(2)时，就先不调用write(2)，只存在cache里，免得被block。但如果已经 超过两秒都还是这个样子，则会硬着头皮执行write(2)，即使redis会被block住。此时那句要命的log会打印：“Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.” 之后用redis-cli INFO可以看到aof_delayed_fsync的值被加1。

因此，对于fsync设为everysec时丢失数 据的可能性的最严谨说法是：如果有fdatasync在长时间的执行，此时redis意外关闭会造成文件里不多于两秒的数据丢失。如果fdatasync 运行正常，redis意外关闭没有影响，只有当操作系统crash时才会造成少于1秒的数据丢失。

解决方法：

然后提了个issue，AOF rewrite时定时也执行一下fdatasync嘛， antirez三分钟后就回复了，新版中，AOF rewrite时32M就会重写主动调用fdatasync。

2、Redis log 一直在报错：background: fork: Cannot allocate memory

Redis数据回写机制

数据回写分同步和异步两种方式

同步回写(SAVE), 主进程直接向磁盘回写数据. 在数据量大的情况下会导致系统假死很长时间

异步回写(BGSAVE), 主进程fork后, 复制自身并通过这个新的进程回写磁盘, 回写结束后新进程自行关闭.

由于 BGSAVE 不需要主进程阻塞, 系统也不会假死, 一般会采用 BGSAVE 来实现数据回写.

故障分析

在小内存的进程上做fork, 不需要太多资源. 但当这个进程的内存空间以G为单位时, fork就成为一件很恐怖的操作.

在16G内存的足迹上fork 14G的进程, 系统肯定Cannot allocate memory.

主机的Redis 改动的越频繁 fork进程也越频繁, 所以一直在Cannot allocate memory

解决方案：

1、redis有个默认的选项：

stop-writes-on-bgsave-error yes

这个选项默认情况下，如果在RDB snapshots持久化过程中出现问题，设置该参数后，Redis是不允许用户进行任何更新操作。

不彻底的解决方式是，将这个选项改为false，但是这样只是当redis写硬盘快照出错时，可以让用户继续做更新操作，但是写硬盘仍然是失败的；

2、彻底的解决方式：直接修改内核参数 vm.overcommit_memory

直接修改内核参数 vm.overcommit_memory = 1, Linux内核会根据参数vm.overcommit_memory参数的设置决定是否放行。

编辑/etc/sysctl.conf ，改vm.overcommit_memory=1

vm.overcommit_memory = 1，直接放行

vm.overcommit_memory = 0：则比较 此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上swap，决定是否放行。

vm.overcommit_memory = 2：则会比较进程所有已分配的虚拟内存加上此次请求分配的虚拟内存和系统当前的空闲物理内存加上swap，决定是否放行。

执行sysctl -p使其生效；

vm.overcommit_memory 的作用

Linux对大部分申请内存的请求都回复"yes"，以便能跑更多更大的程序。因为申请内存后，并不会马上使用内存，将这些不会使用的空闲内存分配给其它程序使用，以提高内存利用率，这种技术叫做Overcommit。一般情况下，当所有程序都不会用到自己申请的所有内存时，系统不会出问题，但是如果程序随着运行，需要的内存越来越大，在自己申请的大小范围内，不断占用更多内存，直到超出物理内存，当linux发现内存不足时，会发生OOM killer(OOM=out-of-memory)。它会选择杀死一些进程(用户态进程，不是内核线程，哪些占用内存越多，运行时间越短的进程越有可能被杀掉)，以便释放内存。

当oom-killer发生时，linux会选择杀死哪些进程？选择进程的函数是oom_badness函数(在mm/oom_kill.c中)，该函数会计算每个进程的点数(0~1000)。点数越高，这个进程越有可能被杀死。每个进程的点数跟（/proc/<pid>/oom_adj）oom_score_adj有关，而且oom_score_adj可以被设置(-1000最低，1000最高)。

当发生oom killer时，会将记录在系统日志中/var/log/messages