1. RDB

1.1 什么是RDB持久化

RDB持久化是在指定时间间隔内，将内存中的数据集快照写入磁盘中
数据集快照可以理解为，在当前时刻，内存中存储的数据

1.2 RDB备份过程

Redis会单独创建子进程进行持久化操作，先将数据写入临时文件，待持久化过程结束后，再用临时文件替换上次持久化好的文件，整个过程中，主进程不进行任何IO操作，这就确保了极高的性能
缺点是最后一次持久化数据可能丢失，比如每隔1分钟做一次持久化，在最后1分钟时，Redis突然宕机，那么这最后一分钟的数据就不会被持久化到磁盘中

1.3 关于RDB持久化的配置

  1. # 在Redis的配置文件中，默认存储数据的文件是dump.rdb
  2. dbfilename dump.rdb   
  4. # dump文件的默认保存路径，可以修改为Redis的安装路径，比如
  5. dir ./  --->  dir /myredis/
  7. # 配置文件中默认的快照配置
  8. save 3600 1      #在1h之内至少对一个key进行修改
  9. save 300 100     # 5min之内至少对100个key进行修改
  10. save 60 10000    # 在1min内至少对10000个key进行修改

当然如果不想等待这么长时间，一个可以修改配置文件中的内容，还有一个可以在命令行中输入save和bgsave命令手动地进行持久化操作

  • save命令只管保存，阻塞其他全部操作，不建议使用
  • bgsave命令Redis会在后台异步进行持久化操作，在保存的同时仍然可以相应客户端的请求

最后一个注意点：使用flushdb或者flushall命令也会生成dump.rdb文件，只不过里面是空的，没有意义

数据恢复操作：将dump.rdb文件拷贝到redis的安装目录下（一般dump.rdb文件为了安全起见会保存在其他机器上），在Redis启动时会自动读取文件内容进行数据恢复

其他的配置文件配置

  1. #表示是否在持久化出错时禁用写操作，默认为yes
  2. stop-writes-on-bgsave-error  yes   
  4. #表示对于磁盘中的数据是否进行压缩操作
  5. rdbcompression  yes

2. AOF

2.1 什么是AOF持久化

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

2.2 AOF持久化过程

  • 客户端中的写操作会被追加到aof缓冲区内
  • aof缓冲区根据aof持久化策略将操作同步到磁盘中的aof文件中
  • redis重启时，会读取aof中的操作内容，恢复数据

    2.3 关于AOF持久化的配置

    ```java

    Redis默认关闭aof持久化

    appendonly no

/* appendfsync表示aof持久化策略，一共有三个值

  1. always：同步持久化，每次发生数据变更后，会被立即记录到aof文件中，这个过程中会阻塞其他写操作 性能较差，但一致性很好
  2. everysec：默认的持久化策略，每秒钟记录一下操作，并异步写入aof文件中，性能很好，一致性也不差 如果在1s内redis服务器宕机，那么只会损失这1s内的数据
  3. no：不采取持久化策略 */ appendfsync everysec

Redis中默认的aof文件名为appendonly.aof

  1. 这个aof文件可以手动打开向文件末尾添加数据（但不建议这样做）；<br />如果在持久化的过程中，导致aof文件损坏，可以在redis的安装目录下，使用redis-check-aof --fix appendonly.aof对aof文件进行修复（其实对于dump.rdb文件也是一样的操作）
  2. <a name="gAdms"></a>
  3. ### 2.4 AOF持久化所存在的问题
  4. 可以看出，aof持久化有一个严重的问题就是，随着客户端的更新操作变多，不断地向aof文件中追加数据，会导致appendonly.aof越变越大，最后影响恢复操作<br />对此，Redis提供了压缩的操作，新增了文件重写机制，当aof文件的大小超过所设定的阈值时，redis就会aof文件进行压缩重写
  5. ```java
  6. #这两个的配置意思是当aof文件的大小超过上次重写时aof文件大小的两倍并且文件大小大于64MB时，会触发重写操作
  7. auto-aof-rewrite-percentage 100
  8. auto-aof-rewrite-min-size 64MB

重写的过程：当aof文件大小超过阈值时，redis会fork出一个子进程对文件进行重写，重写并不是读取旧的aof文件，而是对当前时刻内从中的数据用命令重写一遍，即一条记录有一个set操作，将这些命令写到新的aof文件中

3. RDB与AOF的比较

RDB的优势在于适合大规模的数据恢复，并且rdb文件本身的容量小，可以节省磁盘空间，并且数据恢复速度很快
AOF的优势在于数据一致性比较强，每秒保存一次数据，数据丢失的概率比较小

而RDB方式的不足之处在于数据丢失的概率比较大，因为经过一定时间间隔才会进行一次持久化操作，最后一个时间间隔内丢失数据的概率比较大
AOF的劣势在于，aof文件比较大，时长会因为频繁地更新而不断膨胀，对于大规模的数据恢复极慢，并且每秒进行一次持久化，免不了会有性能的压力

所以到底该选择哪一个持久化策略呢？
这需要根据具体的情况而定：
当数据量较大，并且对数据一致性要求较低的场景，建议使用RDB持久化
当数据量较小，并且对数据一致性要求较高的场景，建议使用AOF持久化
不建议单独使用AOF持久化，因为可能出现bug
如果仅仅使用Redis来做缓存，那么可以都不用

ps：如果在RDB方式与AOF方式都存在的情况下，系统会优先考虑AOF方式进行持久化