redis 持久化

原文地址：http://blog.csdn.net/asdfsadfasdfsa/article/details/68926405?locationNum=2&fps=1

1、rdb(Redis DataBase)

当满足条件时，redis单独会fork（创建）一个新的线程，会先将内存中的数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次已经持久化好了的文件，整个过程中，主进程是不进行任何IO操作的，确保了极高的性能，此时的主进程还可以进行读写操作。rdb数据持久化的缺点是最后一次持久化的数据可能丢失，当在最后一次持久化的时间截点内还没有持久化，此时机器宕机了或出故障了，那么最后一次的数据就没有持久化到。

Fork:fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，也称为原进程的子进程。

如果的内存中的数据量非常大的时候，rdb持久化的临时文件就会非常大，几乎是原文件的1倍，性能有所降低。

如果当写操作要立刻持久化的时候，可以执行命令:save

save是全阻塞的，bgsave是异步的。

flushall也会产生dump.rdb文件，清空所有数据库的数据，并保存在dump.rdb文件中。

shutdown也会产生dump.rdb文件，将内存中数据保存在dump.rdb文件中

 

 

2、aof（Append Only File）

aof的持久化：

aof是对redis的所有写操作的命令将他保存在.aof文件中，包括flushall和flushdb命令也会。当你flushall后，shuntdown了之后重启redis,keys *的数据是空的，因为.aof文件的最后一个写操作的语句是flushall,即使前面做了很多写操作，flushall后，前面的数据都没了。

当aof和rdb同时存在时，会加载aof文件，假如aof文件的语法有误，启动redis是会报错了，就如spring配置文件的bean错了，tomcat也会启动不了。rdb文件也是。

如果aof或rdb文件语法有误，可以使用上面两条命令来修复。

aof修复命令：redis-check-aof --fix appendonlly.aof

rdb修复命令：redis-check-rdb--fix dump.rdb

 

aof是采用文件追加方式，将所有的写操作保存在aof文件中，当文件越来越大时，有可能存在相同的写操作，这些相同的操作可以将他浓缩为一条操作，这样可以减少aof文件的容量。

redis对aof新增了一种重写机制，当aof文件大小超过所设定的阈值时，redis会启动aof文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof。

rewrite的原理：主进程会fork出一条新的进程对文件重写，遍历新进程的内存数据，每条记录有一条set语句。重写aof文件的操作并没有读取旧的aof文件，而是将整个内存的数据内容用命令的方式重写了一个新的aof文件。

触发rewrite的机制：redis会记录上一次重写时aof文件的大小，默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64mb时触发。如果启动redis后没有发生重写的，记录aof文件的大小就启动时加载的aof文件大小。

当redis服务器重启后，会将执行该aof文件，达到数据恢复的目的。

AOF文件重写

为什么要重写？重写可以去除数据的中间执行过程，直接保留最终数据命令。

举个栗子：比如在redis客户端对key执行了一系列命令

set count 1 //初始值为1 
incr count // 加1 
incr count //加1 
decr count //减1

这个时候结果为

get count 
“2”

如果不进行AOF重写的话，进行AOF文件恢复的时候，Redis会执行AOF文件中的每一条命令,并最终得到 count 为2 。

进行AOF重写后，相当于把中间的计算过程略去。直接把计算得到的结果设置进redis，相当于仅执行了一条命令 set count 2。

可以使用BGREWRITEAOF命令来重写AOF文件。

重写策略

重写策略的参数设置：

auto-aof-rewrite-percentage 100

当前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时，会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据。

auto-aof-rewrite-min-size 64mb

限制了允许重写的最小AOF文件大小，通常在AOF文件很小的时候，即使其中有些冗余的命令也是可以忽略的。

RDB 优点

• RDB 是一种表示某个即时点的 Redis 数据的紧凑文件。RDB 文件适合用于备份。例如，你可能想要每小时归档最近 24 小时的 RDB 文件，每天保存近 30 天的 RDB 快照。这允许你很容易的恢复不同版本的数据集以容灾。

• RDB 非常适合于灾难恢复，作为一个紧凑的单一文件，可以被传输到远程的数据中心，或者是 Amazon S3(可能得加密)。

• RDB 最大化了 Redis 的性能，因为 Redis 父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘 IO 这样的操作。

• RDB 在重启保存了大数据集的实例时比 AOF 要快。

RDB 缺点

• 当你需要在 Redis 停止工作(例如停电)时最小化数据丢失，RDB 可能不太好。你可以配置不同的保存点。然而，你通常每隔 5 分钟或更久创建一个 RDB 快照，所以一旦 Redis 因为任何原因没有正确关闭而停止工作，你就得做好最近几分钟数据丢失的准备了。

• RDB 需要经常调用 fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且 CPU 性能不够强大的话，Redis 会停止服务客户端几毫秒甚至一秒。AOF 也需要 fork()，但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。

AOF 优点

• 使用 AOF Redis 会更具有可持久性(durable)：你可以有很多不同的 fsync 策略：没有 fsync，每秒 fsync，每次请求时 fsync。使用默认的每秒 fsync 策略，写性能也仍然很不错(fsync 是由后台线程完成的，主线程继续努力地执行写请求)，即便你也就仅仅只损失一秒钟的写数据。

• AOF 日志是一个追加文件，所以不需要定位，在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令(磁盘满或者其他原因),redis-check-aof 工具也可以很轻易的修复。

• AOF 文件里面包含一个接一个的操作，以易于理解和解析的格式存储。你也可以轻易的导出一个 AOF 文件。例如，即使你不小心错误地使用 FLUSHALL 命令清空一切，如果此时并没有执行重写，你仍然可以保存你的数据集，你只要停止服务器，删除最后一条命令，然后重启 Redis 就可以。

AOF 缺点

• 对同样的数据集，AOF 文件通常要大于等价的 RDB 文件。

• AOF 可能比 RDB 慢，这取决于准确的 fsync 策略。通常 fsync 设置为每秒一次的话性能仍然很高，如果关闭 fsync，即使在很高的负载下也和 RDB 一样的快。不过，即使在很大的写负载情况下，RDB 还是能提供能好的最大延迟保证。

RDB和AOF如何取舍

通常来说，你应该同时使用这两种持久化方法，以达到和 PostgreSQL 提供的一样的数据安全程度。

如果你很关注你的数据，但是仍然可以接受灾难时有几分钟的数据丢失，你可以只单独使用 RDB。

有很多用户单独使用 AOF，但是我们并不鼓励这样，因为时常进行 RDB 快照非常方便于数据库备份，启动速度也较之快，还避免了 AOF 引擎的 bug。