Redis持久化的两种方式

Redis是一个内存数据库，而内存中的数据及易丢失，所以Redis持久化变得非常重要。在Redis中提供了两种持久化的方式，分别是AOF和RDB，Redis默认采用RDB的方式进行持久化。
一、RDB
Redis Database
1、RDB是将数据库中的数据定期以快照的方式存储到磁盘，保存到rdb文件中，并在启动时自动加载rdb文件，以达到持久化的需要。

• 可以在redis的配置文件中设置保存快照的时机：
  save [seconds] [changes]：表示在seconds秒内改变changes次数据就会保存快照到磁盘中（注：save可以同时设置多个）
  如图：
  也可以通过SAVE或BGSAVE命令手动设置快照保存：
  ① SAVE命令：运行此命令时，将会阻塞主进程进行快照保存，直至快照保存完毕，主进程才会继续处理Redis的请求
  ② BGSAVE命令：运行此命令时，将会产生一个子进程进行快照保存，快照保存时不会阻塞主进程，主进程仍然可以处理Redis请求

2、优点

• 会产生一个完整的快照文件，数据可靠
• RDB保存快照时会创建子进程，保存快照时基本不会影响主进程处理请求
• 进行数据恢复时比AOF方式快

3、缺点

• RDB产生的快照并不是实时产生，而是根据配置文件中save的条件定期生成，可能会丢失数据。------（例：配置文件设置的是当有操作时每60秒保存一次快照，但是在59秒时断电了，导致这次的快照没有生成，因此丢失了这次的数据）

二、AOF
Append-Only File（追加写文件）
采用AOF进行持久化时，Redis会把每一次操作都记录到一个文件中，当Redis进行重启时会把AOF产生的文件中的所有操作执行一遍，确保数据恢复到最新。
1、开启AOF
AOF操作默认是关闭，在Redis配置文件中设置appendonly yes即可开启AOF持久化

2、配置AOF

AOF提供了三种fsync配置，在Redis的配置文件中，默认开启第三种：

• appendfsync no：不进行fsync，将flush文件的时机交给OS决定，速度最快
• appendfsync always：每写一条日志就进行一次fsync操作，数据安全性最高，速度最慢
• appendfsync everysec：线程在后台每秒fsync一次

如图：

2、产生的问题及解决方法

• 问题：由AOF介绍可知，每次操作都会放入到AOF产生的文件中，将会产生大量冗余数据。（例：如果我插入a，再接着删除a，重复一百万次，将会产生在AOF文件中产生大量数据，而实际执行这些操作后Redis中一条数据都没有。）

• 解决方法：Redis提供了AOF rewrite功能，可以重写AOF文件，只保留能够把数据恢复到最新状态的最小写操作集。

  在Redis的配置文件中设置这两个属性：

  auto-aof-rewrite-min-size 10mb 
  auto-aof-rewrite-percentage 100  
  

  意思是AOF文件达到10MB的100%的倍数时，即达到20MB时，会调用AOF rewrite功能，将文件进行压缩（例：压缩后会去掉插入a，又删除a这类操作），比如这次将文件压缩到了14MB，下一次将会在文件为28MB时再进行压缩。不断重复以上操作。

  （例：10MB–涨到–>20MB—压缩—>14MB–涨到–>28MB—压缩—>19MB–涨到–>38MB—压缩—>…）

  auto-aof-rewrite-min-size：最开始的AOF文件大小必须要触发这个条件才可以，后面的每次重写就不会根据这个变量了。

3、AOF的优点

• AOF下在配置文件中设置appendfsync为always时，任何已写入的数据都不会丢失，即使设置了appendfsync为everyse，最多也只会丢失1秒的数据

4、AOF的缺点

• 文件比RDB大
• 耗能比RDB高
• 数据恢复比RDB慢