Redis持久化

我们都知道redis作为一个键值对内存数据库（NoSQL），数据都是存储在内存当中，在处理客户端请求是，所有操作都在内存当中进行。但是所有人都知道，存储在内存中的数据，只要服务器关机（各种原因），内存中的数据就会消失了。而且如果redis服务器守护进程退出，内存中的数据也一样会消失。当然只把redis当缓存来用，数据消失问题不大，重新从数据源把数据加载进来就可以了，但是如果用户把业务数据存储在redis中，把redis作为数据库来使用，那么redis的内存数据丢失所造成的影响是毁灭的。

因此为了避免内存中数据丢失，redis提供了对持久化的支持。我们可以选择不同的方式将数据从内存中保存到硬盘当中，使数据可以持久化保存。

Redis持久化方式：

Redis提供了RDB和AOF两种不同的数据持久化方式。

RDB：

RDB 是一种快照存储持久化方式，具体就是将 Redis 某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为 dump.rdb，而在 Redis 服务器启动时，会重新加载 dump.rdb 文件的数据到内存当中恢复数据。

开启RDB持久化：

1.使用save命令即可。当客户端想服务器发送save命令清酒持久化时，服务器会阻塞save命令之后的其他客户端请求，直到数据同步完成。如果数据太大会同步很久，在这期间redis无法接收其他请求，所以在生产环境中最好少使用save命令。


2.使用bgsave命令，其与save不同，bgsave命令是一个异步操作。当客户端发出bgsave命令时，redis服务器主进程会Forks一个子进程来数据同步问题，在将数据保存到RDB文件之后，子进程退出。所以，与 Save 命令相比，Redis 服务器在处理 Bgsave 采用子线程进行 IO 写入。而主进程仍然可以接收其他请求，但 Forks 子进程是同步的，所以 Forks 子进程时，一样不能接收其他请求。这意味着，如果 Forks 一个子进程花费的时间太久（一般是很快的），Bgsave 命令仍然有阻塞其他客户的请求的情况发生。

3.服务器配置自动触发：除了通过客户端发送命令外，还有一种方式，就是在 Redis 配置文件中的 Save 指定到达触发 RDB 持久化的条件，比如【多少秒内至少达到多少写操作】就开启 RDB 数据同步。
例如我们可以在配置文件 redis.conf 指定如下的选项：

之后在启动服务器时加载配置文件即可。

启动服务器加载配置文件

redis-server redis.conf
这种通过服务器配置文件触发 RDB 的方式，与 Bgsave 命令类似，达到触发条件时，会 Forks 一个子进程进行数据同步。不过最好不要通过这方式来触发 RDB 持久化，因为设置触发的时间太短，则容易频繁写入 RDB 文件，影响服务器性能，时间设置太长则会造成数据丢失。

AOF:

与 RDB 存储某个时刻的快照不同，AOF 持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以 Redis 协议追加保存到以后缀为 AOF 文件末尾。
在 Redis 服务器重启时，会加载并运行 AOF 文件的命令，以达到恢复数据的目的。

开启AOF持久化方式：

Redis 默认不开启 AOF 持久化方式，我们可以在配置文件中开启并进行更加详细的配置，如下面的 redis.conf 文件：

对比：

Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。

两种持久化区别：

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

优缺点：

RDB优势：

1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB劣势:

1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF优势：

1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

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

AOF劣势：

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

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

恢复数据的速度比 RDB 慢。

配置：

RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。

总结：

那我们现在是选择RDB还是AOF呢？
其实在应用时主要还是根据自己的实际需求来选择。如果你想要数据足够安全，可以两种方式都开启，但是两种持久化方式同时进行IO操作，会严重影响服务器的性能。当RDB与AOF两种方式都开启的话，redis会优先选择使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。
当然如果你只是单纯把redis作为缓存服务器，那么完全可以不用考虑持久化了。但是如今大多是服务器架构中，redis不单单只是扮演一个缓存服务器的角色，还可以作为数据库保存我们的业务数据，此时还是需要redis持久化策略的。