Redis持久化： .rdb 和 .aof

Redis持久化： .rdb 和 .aof

Redis为什么要持久化? Redis是保存在内存中，断电数据消失。为了能够在重启后也保留数据，则需要对数据持久化。

Redis自带了两种持久化方式：RDB和AOF。

在指定的时间间隔内（可以在service.conf 中找关键字：save “”），将内存的数据集快照（snapshot）写入磁盘,数据恢复时，是直接读取rdb文件到内存。

整个过程，主进程不进行IO操作，确保了高性能。

我们知道save “” 是有多少秒内多少次操作才进行数据集快照保存，所以会存在恰巧不满足条件的那一部分时间的数据没有持久化，从而丢失的可能。如果数据量很大，而且对数据的完整性恢复不那么敏感，那么RDB方式要比AOF方式要高效。

• RDB(Redis DataBase)

没有修改默认配置的话，.rdb文件是在我们的安装目录（可以查看redis.conf文件

# The filename where to dump the DB
# rdb的文件名
dbfilename dump.rdb

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
# rdb文件保存的路径
dir ./

）

触发持久化的条件：

• save条件满足，自动触发RDB规则
• 执行flushall命令，也会立即触发RDB规则
• 退出redis，也触发RDB规则

RDB文件存在，但是提示不能登陆，有可能是文件损毁，如何修复？

​ 在我们的安装目录，可以看到里面有个 redis-check-rdb,启动它，这是redis自带的修复工具。

从其他地方移过来的RDB文件应该放在哪，才能恢复文件里的数据到内存？

​ 在Redis客户端执行

config get dir

​ 得到一个路径，放在这个路径里面就行。

RDB的优缺点：

• 优点：1 适合大规模数据的恢复 2 对数据的完整性要求不高

• 缺点：1 需要一定的时间间隔进程进行操作，如果意外断电，最后一次修改的数据则丢失。 2 fork子进程的时候，会占用一定内存空间。

• AOF(Append Only File)

AOF是什么，是一个文件，可以文本编辑器查看，把我们所有的命令记录下来，数据恢复的时候，再把这个文件全部执行一遍。

通过service.conf中

# Please check http://redis.io/topics/persistence for more information.

# 默认是不开启aof模式的，默认是RDB持久化，大部分情况下，rdb够用
appendonly no

# The name of the append only file (default: "appendonly.aof")
# aof持久化的文件名
appendfilename "appendonly.aof"

设置为yes开启，然后重启生效

持久化规则：

#每次持久化都会sync，消耗性能
# appendfsync always
#每秒执行sync，可能会丢失这一秒的数据
appendfsync everysec
# 永不sync，这个时候操作系统自己去执行同步，速度最快！
# appendfsync no

文件存储大小

#改为yes后，文件会无限变大
no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage 100
#大于64M，则追加一个文件
auto-aof-rewrite-min-size 64mb

修复AOF文件

执行redis-check-aof

优缺点：

• 优点：设置为每一次修改都同步，文件完整性最好；每秒都同步，可能会丢失一秒数据；从不同步，效率最高。
• 缺点：AOF文件大于RDB文件，修复速度慢于RDB；运行速度比RDB慢

总结：

1. RDB持久化能够在指定时间间隔对数据进行数据集快照存储。

2. AOF持久化每次记录写操作，当服务器重启的时候，会重新执行这些命令。

3. 如果单纯作为缓存，希望只是服务器运行的时候这些存在，运行重启后redis没有数据，那么可以不用任何持久化。

4. 同时开启RDB和AOF：这种情况会优先载入AOF文件来恢复数据，因为一般情况AOF比RDB存储的更详细；但是仍推荐用RDB恢复，因为RDB对于大数据量的恢复有优势（速度快，存储量多）

5. 性能建议（摘自狂神说的文章，我还需要消化一下）

   因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够

   了，只保留 save 900 1 这条规则。

   如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自

   己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产

   生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite

   的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重

   写可以改到适当的数值。

   如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也

   减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，

   启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。