Redis持久化
Redis提供多种不同级别的持久化方式：一种是RDB，另一种是AOF。
RDB会根据配置的规则定时将内存中的数据持久化到硬盘上，AOF则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用，但是通常会将两者结合使用。
RDB持久化和AOF持久化之间的异同是非常重要的，以下几个小节将详细地介绍这这两种持久化功能，并对它们的相同和不同之处进行说明。
RDB持久化
RDB持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
RDB方式的持久化是通过快照的方式完成的。当符合某种规则时，会将内存中的数据全量生成一份副本存储到硬盘上，这个过程称作”快照”，Redis会在以下几种情况下对数据进行快照。
- 根据配置规则进行自动快照。
- 用户执行
SAVE,BGSAVE命令。 - 执行
FLUSHALL命令。 - 执行复制（
replication）。执行快照场景
根据配置自动快照，Redis允许用户自定义快照条件，当满足条件时自动执行快照，快照规则的配置方式如下。1
2
3save 900 1
save 300 10
save 60 10000
每个快照条件独占一行，他们之间是或（||）关系，只要满足任何一个就进行快照。上面配置save后的第一个参数T是时间，单位是秒，第二个参数M是更改的键的个数，含义是：当时间T内被更改的键的个数大于M时，自动进行快照。比如save 900 1的含义是15分钟内(900s)被更改的键的个数大于1时，自动进行快照操作。
执行SAVE或BGSAVE命令
除让Redis自动进行快照外，当我们需要重启、迁移、备份Redis时，我们也可以手动执行SAVE或BGSAVE命令主动进行快照操作。
SAVE命令
当执行SAVE命令时，Redis同步进行快照操作，期间会阻塞所有来自客户端的请求，所以放数据库数据较多时，应该避免使用该命令。
BGSAVE命令
从命令名字就能看出来，这个命令与SAVE命令的区别就在于该命令的快照操作是在后台异步进行的，进行快照操作的同时还能处理来自客户端的请求。执行BGSAVE命令后Redis会马上返回OK表示开始进行快照操作，如果想知道快照操作是否已经完成，可以使用LASTSAVE命令返回最近一次成功执行快照的时间，返回结果是一个Unix时间戳。
执行FLUSHALL命令
当执行FLUSHALL命令时，Redis会清除数据库中的所有数据。需要注意的是：不论清空数据库的过程是否触发自动快照的条件，只要自动快照条件不为空，Redis就会执行一次快照操作，当没有定义自动快照条件时，执行FLUSHALL命令不会进行快照操作。
执行复制
当设置主从模式时，Redis会在复制初始化是进行自动快照。
优点
RDB是一个非常紧凑（compact）的文件
它保存Redis在某个时间点上的数据集。这种文件非常适合用于进行备份。
比如说，你可以在最近的24小时内，每小时备份一次RDB文件，并且在每个月的每一天，也备份一个RDB文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
RDB非常适用于灾难恢复（disaster recovery）
它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。
RDB可以最大化Redis的性能
父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘I/O操作。RDB在恢复大数据集时的速度比AOF的恢复速度要快。
缺点
如果你需要尽量避免在服务器故障时丢失数据，那么RDB不适合你。虽然Redis允许你设置不同的保存点（save point）来控制保存RDB文件的频率，但是，因为RDB文件需要保存整个数据集的状态，所以它并不是一个轻松的操作。因此你可能会至少5分钟才保存一次RDB文件。在这种情况下，一旦发生故障停机，你就可能会丢失好几分钟的数据。每次保存RDB的时候，Redis都要fork()出一个子进程，并由子进程来进行实际的持久化工作。在数据集比较庞大时， fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；如果数据集非常巨大，并且CPU时间非常紧张的话，那么这种停止时间甚至可能会长达整整1秒。虽然AOF重写也需要进行fork()，但无论AOF重写的执行间隔有多长，数据的耐久性都不会有任何损失。
RDB快照
在默认情况下，Redis将数据库快照保存在名字为dump.rdb的二进制文件中。你可以对Redis进行设置，让它在”N秒内数据集至少有M个改动”这一条件被满足时，自动保存一次数据集。你也可以通过调用SAVE或者BGSAVE，手动让Redis进行数据集保存操作。
比如说，以下设置会让Redis在满足”60秒内有至少有1000个键被改动”这一条件时，自动保存一次数据集。1
save 60 1000
这种持久化方式被称为快照（snapshot）。
快照的运作方式
当Redis需要保存dump.rdb文件时，服务器执行以下操作。
- Redis调用
fork()，同时拥有父进程和子进程。 - 子进程将数据集写入到一个临时RDB文件中。
- 当子进程完成对新RDB文件的写入时，Redis用新RDB文件替换原来的RDB文件，并删除旧的RDB文件。
- 这种工作方式使得Redis可以从写时复制（copy-on-write）机制中获益。
- 只进行追加操作的文件（append-only file，AOF）。
快照功能并不是非常耐久，如果Redis因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。尽管对于某些程序来说，数据的耐久性并不是最重要的考虑因素，但是对于那些追求完全耐久能力（full durability）的程序来说，快照功能就不太适用。
从1.1版本开始，Redis增加一种完全耐久的持久化方式：AOF持久化。
你可以通过修改配置文件来打开AOF功能。1
appendonly yes
从现在开始，每当Redis执行一个改变数据集的命令时（比如SET），这个命令就会被追加到AOF文件的末尾。这样的话，当Redis重新启时，程序就可以通过重新执行AOF文件中的命令来达到重建数据集的目的。
AOF持久化
AOF持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。AOF文件中的命令全部以Redis协议的格式来保存，新命令会被追加到文件的末尾。Redis还可以在后台对AOF文件进行重写（rewrite），使得AOF文件的体积不会超出保存数据集状态所需的实际大小。
Redis还可以同时使用AOF持久化和RDB持久化。在这种情况下，当Redis重启时，它会优先使用AOF文件来还原数据集， 因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存在。
默认情况下，Redis没有开启AOF（append only file）持久化功能，可以通过在配置文件中作如下配置启用。1
appendonly yes
优点
使用AOF持久化会让Redis变得非常耐久（much more durable），你可以设置不同的fsync策略，比如无fsync，每秒钟一次fsync，或者每次执行写入命令时fsync。AOF的默认策略为每秒钟fsync一次，在这种配置下，Redis仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（fsync会在后台线程执行，所以主线程可以继续努力地处理命令请求）。
AOF文件是一个只进行追加操作的日志文件（append only log），因此对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执行之前的状态。
缺点
对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积。根据所使用的fsync策略，AOF的速度可能会慢于RDB。在一般情况下，每秒fsync的性能依然非常高，而关闭fsync可以让AOF的速度和RDB一样快，即使在高负荷之下也是如此。
不过在处理巨大的写入载入时，RDB可以提供更有保证的最大延迟时间（latency）。AOF在过去曾经发生过这样的BUG：因为个别命令的原因，导致AOF文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令BRPOPLPUSH就曾经引起过这样的BUG。）测试套件里为这种情况添加测试：它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种BUG在AOF文件中并不常见，但是对比来说，RDB几乎是不可能出现这种BUG的。
AOF重写
因为AOF的运作方式是不断地将命令追加到文件的末尾，所以随着写入命令的不断增加，AOF文件的体积也会变得越来越大。
举个例子，如果你对一个计数器调用100次INCR，那么仅仅是为保存这个计数器的当前值，AOF文件就需要使用100条记录（entry）。然而在实际上， 只使用一条SET命令已经足以保存计数器的当前值，其余99条记录实际上都是多余的。处理这种情况，Redis支持一种有趣的特性：可以在不打断服务客户端的情况下，对AOF文件进行重建（rebuild）。执行BGREWRITEAOF命令，Redis将生成一个新的AOF文件，这个文件包含重建当前数据集所需的最少命令。
AOF重写可以在配置文件中做相应的配置，当满足配置的条件时，自动进行AOF重写操作。配置如下。1
2auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
第一行的意思是，目前的AOF文件的大小超过上一次重写时的AOF文件的百分之多少时再次进行重写，如果之前没有重写过，则以启动时AOF文件大小为依据。
第二行的意思是，当AOF文件的大小大于64MB时才进行重写，因为如果AOF文件本来就很小时，有几个无效的命令也是无伤大雅的事情。
这两个配置项通常一起使用。
AOF重写执行步骤
Redis执行fork()，现在同时拥有父进程和子进程。
子进程开始将新AOF文件的内容写入到临时文件。对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有AOF文件的末尾，这样即使在重写的中途发生停机，现有的AOF文件也还是安全的。当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新AOF文件的末尾。现在Redis原子地用新文件替换旧文件，之后所有命令都会直接追加到新AOF文件的末尾。
AOF同步
你可以配置Redis多久才将数据fsync到磁盘一次。
有三个选项
- 每次有新命令追加到AOF文件时就执行一次fsync：非常慢，也非常安全。
- 每秒fsync一次：足够快（和使用RDB持久化差不多），并且在故障时只会丢失1秒钟的数据。
- 从不fsync：将数据交给操作系统来处理。更快，也更不安全的选择。
1
2
3# appendfsync always
appendfsync everysec
# appendfsync no
推荐（并且也是默认）的措施为每秒fsync一次，这种fsync策略可以兼顾速度和安全性。
总是fsync的策略在实际使用中非常慢，即使在Redis 2.0对相关的程序进行改进之后仍是如此，频繁调用fsync注定这种策略不可能快得起来。
AOF文件出错
服务器可能在程序正在对AOF文件进行写入时停机，如果停机造成AOF文件出错（corrupt），那么Redis在重启时会拒绝载入这个AOF文件，从而确保数据的一致性不会被破坏。
应该选用哪一个
一般来说，如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。有很多用户都只使用AOF持久化，但我们并不推荐这种方式。因为定时生成RDB快照（snapshot）非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免之前提到的AOF程序的BUG。因为以上提到的种种原因，未来我们可能会将AOF和RDB整合成单个持久化模型。
Redis持久化磁盘IO方式及其带来的问题
有Redis线上运维经验的人会发现Redis在物理内存使用比较多，但还没有超过实际物理内存总容量时就会发生不稳定甚至崩溃的问题，有人认为是基于快照方式持久化的fork系统调用造成内存占用加倍而导致的，这种观点是不准确的，因为fork调用的copy-on-write机制是基于操作系统页这个单位的，也就是只有有写入的脏页会被复制，但是一般你的系统不会在短时间内所有的页都发生写入而导致复制，那么是什么原因导致Redis崩溃的呢？
答案：Redis的持久化使用Buffer IO造成的，所谓Buffer IO是指Redis对持久化文件的写入和读取操作都会使用物理内存的Page Cache，而大多数数据库系统会使用Direct IO来绕过这层Page Cache并自行维护一个数据的Cache，而当Redis的持久化文件过大（尤其是快照文件），并对其进行读写时，磁盘文件中的数据都会被加载到物理内存中作为操作系统对该文件的一层Cache，而这层Cache的数据与Redis内存中管理的数据实际是重复存储的，虽然内核在物理内存紧张时会做Page Cache的剔除工作，但内核很可能认为某块Page Cache更重要，而让你的进程开始Swap，这时你的系统就会开始出现不稳定或者崩溃。我们的经验是当你的Redis物理内存使用超过内存总容量的3/5时就会开始比较危险。
