redis 重启_Redis 持久化的两种方式：AOF、RDB

摘要：Redis 对比 Memcache，还有一个最大的区别，就是 Redis 的数据持久化机制。Redis 数据持久化有两种方式，AOF和RDB，本文将用简单的文字和流程图完成持久化这个知识点的讲解。

1、Redis 的持久化机制

高效：Redis 是一个内存数据库，所有的数据都以Key - Value 的方式存储在内存中，当处理客户端请求时，所有的操作都发生在内存当中，这也就是Reids处理速度高的原因之一。

风险：数据存在内存中会有一个很大的风险，如果Redis-Server 的守护进程挂掉或服务器出现重启或关机，内存中的数据也回随之消失。

持久化机制：为了避免出现数据丢失的风险，Redis 采用了持久化机制，有效的将内存中的数据保存在硬盘上，实现数据持久化。

2、RDB 和 AOF

Redis 在持久化机制上提供了两种解决办法，放别是 RDB 和 AOF。

RDB 方式

可以理解为“快照方式”，类似VM或云服务器的快照功能。就是在某一时间内，将Redis在内存中的全部数据导出，存储到硬盘上的一个叫dump.rdb(默认文件名)的文件中。当服务器重启时，会从dump.rdb文件中加载数据到内存中，完成数据的恢复，实现数据持久化机制。

如何触发RDB？

自动触发和手动触发，我们先说一下自动触发。

自动触发通过修改redis.conf 文件中的 save 部分的配置信息实现，找到这个部分，配置信息和注释如下：

save 900 1     #表示900 秒内如果至少有 1 个 key 的值变化，则保存save 300 10    #表示300 秒内如果至少有 10 个 key 的值变化，则保存save 60 10000  #表示60 秒内如果至少有 10000 个 key 的值变化，则保存############### 修改redis.conf 文件后，需要重新加载配置文件##############redis-server redis.conf#################其他RDB 配置 ###########是否压缩 dump.rdb文件rdbcompression yes#修改默认的 dump.rdb 文件名称，如：多个 redis ，可以使用端口号区分dbfilename  redis_6379.rdb# dump.rdb 文件保存位置dir /usr/local/redis_rdb_back/#####################################

通过配置save ，当触发条件满足后触发RDB持久化，如：当900s内至少有一个key发生变化，就执行RDB持久化来快照数据。

手动触发RDB，需要执行 save 命令 或 bgsave 命令，这样 Redis 就在服务器的硬盘上产生一个dump.rdb文件，用来持久化数据了。

#同步操作

save 命令为同步操作，这是一个阻塞方式，在服务器执行RDB时会阻塞所有其他请求，直至RDB执行完毕，可以试想一下，如果数据量巨大，执行时间就会变长，其他的请求就出现等待，超时等一系列状况。所以这个命令和 “keys *” 一样，尽量不要在生产环境中使用。

#异步操作bgsave

bgsave命令执行时采用子进程程完成资源操作，当客户端发出bgsave 命令后，服务端forks一个子进程处理数据持久化操作，当数据完全写入 dump.rdb 文件中后，子进程自动回收。

这样的好处是，主进程依旧存在，可以处理其他客户端请求，持久化请求交给forks 的一个子进程完成，主进程和子进程是同步的。

总结：

1、实现RDB方式有两种方式，手动方式：执行命令，save 和 bgsave ，一个是同步，一个是异步。

配置方式：配置redis.conf 文件 save 部分实现，配置文件方式相当于执行了 bgsave 命令。

2、RDB 生成 dump.rdb 文件

生成RDB临时文件后，开始写入数据。

所有数据写入完成后，用临时文件代替正式RDB文件。

删除原来 RDB 文件。

-----------------------------漂亮的分割线-----------------------------

AOF方式

append only file 会记录客户端对服务端的每次请求命令，将记录追加到后缀为aof的文件尾部。

在Redis服务重启后，运行AOF文件中的命令，恢复数据。

aof 文件中的数据为二进制格式，aof 的方式类似mysql 的binlog。

AOF 持久化机制是采用修改 redis.conf 配置文件实现的，具体配置如下：

# 开启aof机制 appendonly yes  # 定义 aof 文件名 appendfilename "appendonly.aof"  # 写入策略,always表示每个写操作都保存到aof文件中,也可以是everysec或no appendfsync always  # appendfsync everysec # appendfsync 的默认写入策略，每秒写入一次 AOF 文件，如发生异常，最多可能会丢失 1s 的数据。# appendfsync no # Redis 服务器不负责写入 AOF，而是交由操作系统来处理什么时候写入 AOF 文件。更快，但也是最不安全的选择，不推荐使用。 # 默认不重写aof文件 no-appendfsync-on-rewrite no  # 保存目录 dir ~/redis/ 

AOF 还有一个需要注意的问题，如果在写入aof 文件的时候，服务器因异常宕机，那么这个aof 文件就会出现格式错误，重启服务器后，redis加载 aof 文件就会报错，这时候需要修复 aof 文件，具体命令如下：

#修复 aof 文件redis-check-aof -fix appendonly.aof#重启redis server

总结：

aof 类似mysql binlog ，采用追加日志方式，对服务器性能影响小，速度较rdb快。但是生成的文件较大，恢复数据比rdb 要慢。

最后到底是用 rdb 还是 aof 那，这个要结合生产环境灵活应用，下面给出一个 rdb 和 aof 对比图，同学们自行选择合适的持久化方式吧。