Redis持久化方式

目录

Redis简介：

Redis持久化方式有两种：

RDB:

AOF:

RDB和AOF如何选择

---

Redis简介：

Redis是一种基于内存操作的键值对非关系型数据库，其操作均在内存中完成；可以存储五种数据类型：String类型、List类型（有序可重复）、set类型（无序无重复）、zset类型、hash类型。

Redis持久化方式有两种：

为什么要持久化？懂一点电脑知识的人都会明白，当电脑断电或服务器关闭之后，内存中的数据会消失；如果作为数据库那么对企业则是致命的打击，所以Redis一般都当作缓存使用；这样的话如果服务器关闭之后只需要重新从数据库读取数据到Redis中就行。当然Redis也提供了持久化方式来解决数据丢失的问题，我们可以选择不同的方式将数据从内存中持久化到本地磁盘中，使数据能够长久保存。

RDB:

RDB(Relation DataBase) 是一种快照存储持久化方式，实际就是将某一时刻的内存数据保存到硬盘的文件夹中，并且默认文件名为dump.rdb，当Redis服务器重新启动的时候，就会重新加载dump.rdb文件，将数据恢复到内容中。

开启RDB持久化的方式：

客户端向Redis服务器发送Sava或者BGSave命令让服务器生成RDB文件，或者通过服务器配置文件指定触发生成RDB文件的条件。

Save命令是一种同步操作，也就是当客户端向Redis服务器发送save命令时，服务器会阻塞save命令之后的其他命令请求，直到到将数据持久化完成。如果数据量很大的话，会持续很久，而导致服务器不能接收完成其他命令请求，因此最好不要使用该命令。

BgSave命令是一种异步操作，也就是当客户端向Redis服务器发送BgSave命令时，Redis服务器会forks一个子进程去执行同步任务，将数据保存到RDB文件后，子进程会退出。当子进程同步数据时，主进程依然可以接收执行其他请求，但是子进程还是不能接收执行其他的请求；如果子进程需要大量的时间去处理同步数据，那么依然有可能会阻塞其他命令请求的可能。

Redis配置文件触发同步数据：Save指定到达触发RDB持久化的条件，比如（多少秒内至少达到多少写操作），就开启RDB数据同步的命令。

配置如下：

save 600 100  #600秒内至少达到一百条命令

在服务器启动时加载配置文件就行。

RDB文件：

生成RDB文件过程如下：

生成临时RDB文件，并写入数据----->写入数据完成，用临时文件代替正式文件 -----> 删除原来的RDB文件

RDB文件命名：

dbfilename redis-6735.rdb

RDB文件保存目录：

dir ~/redis/

RDB优点：

1、RDB 文件非常紧凑，适合于数据备份；

2、与 AOF 方式相比，通过 RDB 文件恢复数据比较快；

3、使用子进程生成，对 Redis 服务器性能影响较小。

RDB缺点：

1、使用 Save 命令会造成服务器阻塞，直接数据同步完成才能接收后续请求；

2、使用 Bgsave 命令在 Forks 子进程时，如果数据量太大，Forks 的过程也会发生阻塞，另外，Forks 子进程会耗费内存；

3、如果服务器宕机的话，采用 RDB 的方式会造成某个时段内数据的丢失，比如我们设置 10 分钟同步一次或 5 分钟达到 1000 次写入就同步一次，那么如果还没达到触发条件服务器就死机了，那么这个时间段的数据会丢失。

AOF:

AOF(Append Only File)会记录客户端对服务器的每一次操作命令，并将其追加保存到以AOF结尾的文件中的末尾处。当服务器重启时，会运行加载AOF文件的命令恢复数据。

开启AOF持久化方式：

Redis默认不开启AOF持久化，开启的话需要在配置文件redis.conf中添加配置，如下：

#开启aof机制
appendonly yes

#aof文件名
appendfilename "appendonly.aof"

#写入策略 always 表示每个操作都保存  everysec表示每秒一次   no  表示不写入
appendfsync always

#默认不重写aof文件
no-appendfsync-on-rewrite no

#保存目录
dir ~/redis/

三种写入策略： 

appendfsync always ：表示每一个操作都保存到aof文件中，最安全的策略，由于每个文件都要保存就会导致效率慢；

appendfsync everysec ：表示每秒写入一次aof文件，会丢失一些数据；

appendfsync no ： 表示Redis 服务器不负责写入 AOF，而是交由操作系统来处理什么时候写入 AOF 文件。更快，但最不安全的选择。

AOF文件重写：

AOF 将客户端的每一个写操作都追加到 AOF 文件末尾，比如对一个 Key 多次执行 Incr 命令，这时候，AOF 保存每一次命令到 AOF 文件中，AOF 文件会变得非常大。如下：

incr num 1 
incr num 2 
incr num 3 
incr num 4 
incr num 5 
 ... 
incr num 200000

那么在加载aof文件的时候就会很慢，影响效率。为了解决这个问题，Redis 支持 AOF 文件重写。通过重写 AOF，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：

set num 100000 

 两种重写方式：

通过在 redis.conf 配置文件中的选项 no-appendfsync-on-rewrite 可以设置是否开启重写。这种方式会在每次 Fsync 时都重写，影响服务器性能，因此默认值为 no，不推荐使用。

通过客户端向服务器发送 bgrewriteaof 命令，让服务器进行 AOF 重写。

AOF文件损坏修复：

当写入数据到AOF中时，如果服务器宕机，就会损坏aof文件,服务器重启时就会拒绝加载这个aof文件；为了解决这种其情况，我们可以使用如下命令修复数据：

#修复aof日志文件

$redis-check-aof -fix file.aof

重启服务器就会加载已经修复得aof文件，恢复数据。

AOF优点：

1、AOF 只是追加日志文件，对服务器性能影响较小，速度比 RDB 要快，消耗的内存较少。

AOF缺点：

1、恢复数据的速度比 RDB 慢；

2、AOF 方式生成的日志文件太大，即使通过 AFO 重写，文件体积仍然很大。

RDB和AOF如何选择

方式	RDB	AOF
启动优化级	低	高
体积	小	大
速度	快	慢
安全性	数据丢失	策略决定
轻重	重	轻

从以上几点对比，可以根据具体情况选择；