1.RDB长久化形式可能在指定的工夫距离能对你的数据进行快照存储。
2.AOF长久化形式记录每次对服务器写的操作，当服务器重启的时候会从新执行这些命令来复原原始的数据，AOF命令以redis协定追加保留每次写的操作到文件开端。Redis还能对AOF文件后盾重写，使得AOF文件的体积不至于过大。
3.如果你只心愿你的数据在服务器运行的时候存在，你也能够不应用任何长久化的形式。
4.你也能够同时开启两种长久化形式，在这种状况下，当redis重启的时候会优先载入AOF文件来复原原始的数据。因为在通常状况下AOF文件保留的数据集要比RDB文件保留的数据集要残缺。

2、RDB

1、概念

在指定的工夫距离内将内存中的数据集快照写入磁盘中，它复原的时候是将快照中的文件间接读取到内存中。

2、长久化机制-BGSAVE

通常，会立刻返回ok,Redis过程会执行fork操作创立子过程，Redis在fork时，父过程会持续为客户端提供服务，子过程会将数据长久化到硬盘上，而后退出。如果曾经在后盾执行保留或者正在运行另一个非后盾保留的过程，特地是正在进行AOF写入时，则会返回谬误。如果应用了bgsave工作，而正在进行AOF写入时，该命令将立刻返回ok,并打算在下一次机会运行后盾保留。阻塞只会在fork阶段。
客户端能够应用lastsave命令查看操作是否胜利。

3、长久化机制-SAVE

不会承受客户端执行的操作命令，等长久化工作实现之后，会将新的文件替换旧的文件。

4、长久化机制-主动触发

在redis.conf中能够配置，让用户自定义save属性，让服务器每一段时间内执行一次bgsave操作。

  # 服务器在900秒内，对数据库进行了至多1次批改
  save 900 1
  
  # 服务器在300秒内，对数据库进行了至多10次批改
  save 300 10
  
  # 服务器在60秒内，对数据库进行了至多10000次批改
  save 60 10000
  
  # bgsave产生谬误时是否进行写入，个别为yes
  stop-writes-on-bgsave-error yes
  
  # 长久化时是否应用LZF压缩字符串对象?
  rdbcompression yes
  
  # 是否对rdb文件进行校验和测验，通常为yes
  rdbchecksum yes
  
  # RDB长久化文件名
  dbfilename dump.rdb
  
  # 长久化文件存储目录
  dir ./

5、复原数据机制

只须要将rdb文件放在咱们redis启动目录就能够了，redis启动的时候会主动查看文件并复原其中的数据。

6、长处

RDB是一个十分紧凑的文件，它保留了某个工夫点得数据集，十分实用于数据集的备份，比方你能够在每个小时报保留一下过来24小时内的数据，同时每天保留过来30天的数据，这样即便出了问题你也能够依据需要复原到不同版本的数据集。
RDB是一个紧凑的繁多文件，很不便传送到另一个远端数据中心或者亚马逊的S3（可能加密），十分实用于劫难复原。
RDB在保留RDB文件时父过程惟一须要做的就是fork出一个子过程，接下来的工作全副由子过程来做，父过程不须要再做其余IO操作，所以RDB长久化形式能够最大化redis的性能。
与AOF相比，在复原大的数据集的时候，RDB形式会更快一些。

7、毛病

如果你心愿在redis意外进行工作（例如电源中断）的状况下失落的数据起码的话，那么RDB不适宜你。尽管你能够配置不同的save工夫点(例如每隔5分钟并且对数据集有100个写的操作)，是Redis要残缺的保留整个数据集是一个比拟沉重的工作，你通常会每隔5分钟或者更久做一次残缺的保留，万一在Redis意外宕机，你可能会失落几分钟的数据。
RDB 须要常常fork子过程来保留数据集到硬盘上，当数据集比拟大的时候，fork的过程是十分耗时的，可能会导致Redis在一些毫秒级内不能响应客户端的申请。如果数据集微小并且CPU性能不是很好的状况下，这种状况会继续1秒，AOF也须要fork，然而你能够调节重写日志文件的频率来进步数据集的耐久度。

3、AOF

1、概念

以日志的模式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不能够改写文件，Redis启动之初会读取该文件从新构建数据，换言之，Redis重启的话就会依据日志文件的内容将写的指令从前到后执行一次以实现数据的复原工作。

2、长久化原理

所有操作的命令会追加在文件中。

3、开启AOF长久化

   
   # 开启aof长久化形式，默认no
   appendonly no
   
   # aof 长久化生成的文件名称
   appendfilename "appendonly.aof"
   
   # 三种长久化机制
   # appendfsync always
   appendfsync everysec
   # appendfsync no

4、三种触发长久化机制

always

同步长久化，每次产生数据变更会被立刻长久化到硬盘中，性能比拟差，然而数据完整性好。

everysec

异步操作，每秒长久化数据到硬盘一次，可能会失落一秒的数据。

从不长久化到硬盘。

5、AOF文件损坏

如果 aof 文件被毁坏，redis服务是启动不了的。redis自身提供了修复了工具。redis-check-aof --fix appendonly.aof

5、长处

依据配置不同的策略，让你抉择长久化的形式。
AOF文件是一个只进行追加的日志文件，所以不须要写入seek，即便因为某些起因(磁盘空间已满，写的过程中宕机等等)未执行残缺的写入命令，你也也可应用redis-check-aof工具修复这些问题。
Redis 能够在 AOF 文件体积变得过大时，主动地在后盾对 AOF 进行重写：重写后的新 AOF 文件蕴含了复原以后数据集所需的最小命令汇合。整个重写操作是相对平安的，因为 Redis 在创立新 AOF 文件的过程中，会持续将命令追加到现有的 AOF 文件外面，即便重写过程中产生停机，现有的 AOF 文件也不会失落。而一旦新 AOF 文件创建结束，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
AOF 文件有序地保留了对数据库执行的所有写入操作，这些写入操作以 Redis 协定的格局保留，因而 AOF 文件的内容非常容易被人读懂，对文件进行剖析（parse）也很轻松。导出（export）AOF文件也非常简单：举个例子，如果你不小心执行了 FLUSHALL 命令，但只有 AOF 文件未被重写，那么只有进行服务器，移除 AOF 文件开端的 FLUSHALL 命令，并重启 Redis，就能够将数据集复原到 FLUSHALL 执行之前的状态。

6、毛病

对于雷同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
依据所应用的 fsync 策略，AOF 的速度可能会慢于 RDB 。在个别状况下，每秒 fsync 的性能仍然十分高，而敞开 fsync 能够让 AOF 的速度和 RDB 一样快，即便在高负荷之下也是如此。不过在解决微小的写入载入时，RDB 能够提供更有保障的最大延迟时间（latency）。

4、如何抉择长久化机制

开启两种长久化形式，依据本人的业务需要针对redis进行配置的调整。

关于redis:Redis第七章节持久化

目录

1、概述

2、RDB

3、AOF

4、如何抉择长久化机制