本文主要是介绍Redis（2）---数据持久化，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

数据持久化

Redis有两种持久化的方式：快照（RDB文件）和追加式文件（AOF文件）

    （1）RDB持久化方式是在一个特定的间隔保存某个时间点的一个数据快照。（默认模式）

    （2）以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作 。

注意：Redis的持久化是可以禁用的，两种方式的持久化是可以同时存在的，但是当Redis重启时，AOF文件会被优先用于重建数据。

一、RDB

1、是什么？

           在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
    Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
    整个过程中，主进程是不进行任何IO操作的，这就确保了如果需要进行大规模数据的恢复时还能有极高的性能。

2.文件路径和名称

默认Redis会把快照文件存储为当前目录下一个名为dump.rdb的文件。要修改文件的存储路径和名称，可以通过修改配置文件redis.conf实现：

# RDB文件名，默认为dump.rdb。
dbfilename dump.rdb

# 文件存放的目录，AOF文件同样存放在此目录下。默认为当前工作目录。
dir ./

3.redis.conf如何配置

保存点可以设置多个，Redis的配置文件就默认设置了3个保存点：

# 以下配置表示的条件：
# 服务器在900秒之内被修改了1次
save 900 1
# 服务器在300秒之内被修改了10次
save 300 10
# 服务器在60秒之内被修改了10000次
save 60 10000

#如果想禁用快照保存的功能，可以通过注释掉所有"save"配置达到，或者在最后一条"save"配置后添加如下的配置：
save ""

4、如何启动快照
有四种方式：
  （1）在配置文件中你配置保存点，而不是save ""，当达到要求会进行快照。

  （2）SAVE命令：SAVE命令会使用同步的方式生成RDB快照文件，这意味着在这个过程中会阻塞所有其他客户端的请求。因此不建议在生产环境使用这个命令。

  （3）BGSAVE命令：BGSAVE命令使用后台的方式保存RDB文件，调用此命令后，会立刻返回OK返回码。Redis会产生一个子进程进行处理并立刻恢复对客户端的服务。在客户端我们可以使用LASTSAVE命令查看操作是否成功。
  （4）执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。

   注意：配置文件里禁用了快照生成功能不影响SAVE和BGSAVE命令的效果。

二、AOF

1.AOF是什么？

       以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作 。

      注意：Aof保存的是appendonly.aof文件

2、AOF启动、修复、恢复

（1）正常启动
        修改默认的appendonly no，改为yes（因为redis默认是RDB持久化，所以这里需要在redis.conf手动开启）

（2）如果启动失败，有可能是你的appendonly.aof有误（比如因为磁盘满了，命令只写了一半到日志文件里，我们也可以用redis-check-aof这个工具很简单的进行修复。）

具体做法：
     redis-check-aof --fix进行修复

3、同步策略。

它有三种同步策略：appendfsync always(每修改同步), appendfsync everysec(每秒同步)， appendfsync no （不同步）

  （1）appendfsync always(每修改同步)： 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好。

  （2）appendfsync everysec(每秒同步)：异步操作，每秒记录. 如果发生灾难，您可能会丢失1秒的数据。

    (3)appendfsync no （不同步）：从不同步。

官方建议使用默认配置每秒同步，它既快速又安全。这个always策略在实践中非常缓慢， 没有办法做得fsync比现在更快。

4、AOF重写

 （1）是什么？

      AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，

只保留可以恢复数据的最小指令集.

（2）重写原理

       AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，

而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

（3）触发机制

       Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发（redis默认是64M进行重新一次，而实际生产环境这里至少要2G）

三、RDB和AOF优缺点

1、RDB的优点

（1）比起AOF，在数据量比较大的情况下，RDB的启动速度更快。

（2）RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合用于做备份。

（3）RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。

（4）RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。

2、RDB缺点

（1）RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。

（2）RDB使用fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，造成Redis停止服务几毫秒。

3、AOF优点

（1）该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，如果发生灾难，您只可能会丢失1秒的数据。

（2）AOF日志文件是一个纯追加的文件。就算服务器突然Crash，也不会出现日志的定位或者损坏问题。甚至如果因为某些原因（例如磁盘满了）命令只写了一半到日志文件里，我们也可以用redis-check-aof这个工具很简单的进行修复。

（3）当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。

4、AOF缺点

（1）在相同的数据集下，AOF文件的大小一般会比RDB文件大。

（2）在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。

四、RDB和AOF建议

（1）官方建议：是同时开启两种持久化策略。因为有时需要RDB快照是进行数据库备份，更快重启以及发生AOF引擎错误的解决办法。（换句话就是通过RDB来多备份一份数据总是好的）

（2） 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。

（3）如果选择AOF，只要硬盘许可，应该尽量减少AOF rewrite的频率。因为一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。

    AOF重写的基础大小默认值64M太小了，可以设到5G以上。

这篇关于Redis（2）---数据持久化的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！