Redis的持久化

    Redis的高性能是由于它所有的数据都存储在内存中，为了使RRedis在重启之后，仍然能保证数据不丢失，那么就需要将数据从内存当中同步到硬盘上，这个过程称为 持久化操作。

两种持久化方式

• RDB方式
• AOF方式

持久化使用的方式

• RDB持久化
  
  
      在指定的时间间隔内，将内存中的数据集快照写入到磁盘中。

• AOF持久化
  
  
      以日志的形式，记录服务器所处理的每一个操作。在Redis服务器启动之初，会读取该文件来构建整个数据库。

• 无持久化
  
  
      可以通过配置来禁用持久化的使用功能。

• 同时使用RDB和AOF

---

RDB

• 优势
  
  
      只包含一个文件，易于文件备份以及拷贝，出现灾难性故障容易恢复。性能最大化，相比AOF，对于大数据集，启动效率更高。

• 劣势
  
  
      若想保证数据的高可用性，即最大限度的避免数据的丢失，RDB将不是很好的选择。因为系统如果在定时持久化之前出现一些宕机的情况，那么就会造成数据的丢失。

• 配置
  
  
  在redis.conf的第147~149行，出现以下代码

    save 900 1  #每900s至少有1个key发生变化，则持久化一次（dump内存的一个快照）
    save 300 10 #每300s至少有10个key发生变化，则往硬盘写一次
    save 60 10000   #每60s至少有10000个key发生变化，则写一次

---

AOF

• 优势
  
  
      这种机制可以带来更高的安全性。Redis中提供了三种同步策略，每秒同步，每修改同步和不同步。事实上每秒同步也是异步完成的，它的效率也是非常高的，所差的是一旦系统出现宕机的情况，那么这一秒钟之内修改的数据就会丢失了。每修改同步可以将其视为同步持久化，每一次发生数据的变化，都会立即记录到磁盘当中，这种效率是最低的，但是是最安全的。
  
  
      由于这种机制对于日志文件的写入操作采用的是append(追加)模式，因此在写入过程中，即使出现了宕机的现象，也不会破坏日志文件中已经存在的内容。对于日志文件写入一半发生宕机的情况，在Redis下一次启动之前，可以通过Redis-Check-AOF这个工具来解决数据一致性的问题。如果日志过大，Redis可以自动启动重写机制。
  
  
      Redis的append模式不断地将修改的数据写入老的磁盘文件中，同时Redis还会创建一个新的文件来记录在此期间产生了哪些修改命令被执行了。因此，在进行重写切换的时候，可以更好地去保护数据的安全性。
  
  
      AOF包含一个格式非常清晰，易于理解的日志文件，用于记录所有的修改操作，也可以通过这个文件来完成数据的重建。

• 劣势
  
  
      对于相同数量的数据集而言，AOF的这个文件要比RDB的文件要大一些。根据同步策略的不同，AOF在运行效率上往往会低于RDB。

• 配置
  
  
  在redis.conf的第509行，出现以下代码。

    appendonly no   #默认情况下AOF方式不打开
    #若打开aof，将产生appendonly.aof文件在/root目录下

在redis.conf的第538行，出现以下代码。

    # appendfsync always    #每修改同步
    appendfsync everysec    #每秒同步
    # appendfsync no        #不同步

AOF的启动

• 在redis.conf中修改appendonly为yes
• 选择的同步策略（建议选择每修改同步）
• 关闭redis服务（shutdown命令）
• 启动redis服务