Redis的持久化

 

 Redis的持久化有两种方式：

• RDB方式(默认支持)：在指定的时间间隔内将内存中的数据集快照写入磁盘
• 优势
  • 整个Redis数据库将只包含一个文件，对于文件备份来说是完美的，系统出现灾难性的故障时容易恢复
  • 性能最大化，开启服务器时，只需要做的是分叉出一些进程，再由子进程来完成持久化操作，极大的避免服务器进程执行IO流操作。数据集很大时，比AOF启动更高效
• 劣势配置
  • 在保持数据的高可用性时(最大限度的避免数据丢失)，RDB不是好的选择。系统一定在定时持久化之间出现宕机时，还没有来得及往硬盘上写时，数据就已经丢失
  • RDB通过分叉方式的子进程来协助完成数据持久化操作，因此在数据集很大时，可能导致整个服务器停止几百ms甚至1s
• 在redis.conf中的
  save 900 1 每900s 至少1个key发生变化
  save 300 10 每300s 至少10个key发生变化
  save 60 10000 每60s至少10000个key发生变化
  满足以上，会写入一次
• 在redis.conf的：RDB的默认文件名 dbfilename dump.rdb
  保存路径：dir ./

• AOF方式：将以日志的形式记录服务器的每一个操作，在服务器启动时会读取该文件来重新构建数据库，保证启动后数据库中的数据是完整的

• 优势
  • 数据更高的安全性
    • Redis提供三种同步策略：每秒、每修改(同步持久化,效率最低最安全)、不同步
  • 对日志的写入操作采用append追加方式，在写入时即使出现宕机，也不会破坏日志文件中已经存在的内容(若一次操作只写入了一半数据就系统崩溃，在Redis下次启动之前使用redis -check -aof来解决数据一致性问题)
  • 如果日志过大，Redis会自动启动重写机制，以append方式不断将修改的数据写入到老的磁盘当中，同时还会创建一个新的文件，来记录此期间产生的哪些修改命令被执行。在进行重写切换时，可以更好的保证数据的安全性
  • AOF包含一个格式清晰易于理解的日志文件用于记录所有的修改操作(可以用它来完成数据的重建)
• 劣势
  • 对于相同数据量的数据集，AOF的文件比RDB的更大
  • 根据同步策略的不同，AOF的运行效率低于RDB
• 配置
  • redis.conf的
    • appendonly no变为yes
      会产生appendfilename "appendonly.aof"
    • #appendfsync always每修改一次同步
      appendsync everysec每秒同步
      #appendfsync no不同步
• 若误删数据，通过修改appendonlu.aof文件中的命令，再重新启动来恢复数据