一、Redis提供了哪些持久化机制
1). RDB持久化：
该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
2). AOF持久化:
该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。
3). 无持久化：
我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。
4). 同时应用AOF和RDB。
5). 如果要开启AOF模式，修改Redis的配置文件redis.conf。
# 相关配置
appendonly yes #开启AOF模式 原文1
appendfilename "appendonly.aof" #保存数据的AOF文件名称 原文1
# appendfsync always
appendfsync everysec #fsync模式 原文2
# appendfsync no
no-appendfsync-on-rewrite no #原文3
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb #原文4
aof-load-truncated yes #原文5官方文档解释如下：
原文1：
By default Redis asynchronously dumps the dataset on disk. This mode is good enough in many applications, but an issue with the Redis process or a power outage may result into a few minutes of writes lost (depending on the configured save points).
The Append Only File is an alternative persistence mode that provides much better durability. For instance using the default data fsync policy (see later in the config file) Redis can lose just one second of writes in a dramatic event like a server power outage, or a single write if something wrong with the Redis process itself happens, but the operating system is still running correctly.
AOF and RDB persistence can be enabled at the same time without problems. If the AOF is enabled on startup Redis will load the AOF, that is the file with the better durability guarantees.
译文1：
Redis默认采用异步的方式将数据存放到磁盘上，这个模式对大部份应用来说是足够好的，但是在Redis进程或电源发生故障的情况下，可能会造成小部份的数据丢失，这取决于配置的保存时间点。
Appendonly是一种能够提供非常好的持久化的模式，例如使用默认的Fsync方案，Redis能在发生服务器电源故障或操作系统仍然正常运行但Redis进程莫名挂掉的情况下，只丢失1秒的数据。
AOF与RDB模式可以同时启用，这并不冲突。如果AOF是可用的，那Redis启动时将自动加载AOF，这个文件能够提供更好的持久性保障。
原文2：
The fsync() call tells the Operating System to actually write data on disk instead of waiting for more data in the output buffer. Some OS will really flush data on disk, some other OS will just try to do it ASAP.
Redis supports three different modes:
no: don’t fsync, just let the OS flush the data when it wants. Faster.
always: fsync after every write to the append only log. Slow, Safest.
everysec: fsync only one time every second. Compromise.
The default is “everysec”, as that’s usually the right compromise between speed and data safety. It’s up to you to understand if you can relax this to “no” that will let the operating system flush the output buffer when it wants, for better performances (but if you can live with the idea of some data loss consider the default persistence mode that’s snapshotting), or on the contrary, use “always” that’s very slow but a bit safer than everysec.
If unsure, use “everysec”.
译文2：
fsync()调用告诉操作系统将数据真实的写入磁盘而不是放到缓冲区中，一些操作系统会真实的执行请求，还有一些操作系统只会尽力的尝试。
Redis支持3种不同的模式：
no：不即时同步，由操作系统控制何时刷写到磁盘上，这种模式速度最快；
always：每次只写日志，速度较慢，但最安全；
everysec：每秒钟同步一次，折中的方案。
默认的模式是“everysec”，它通常是在速度和数据安全之间折中的方法。如果你可以控制操作系统在Redis需要的时候去刷写缓冲区那可以使用“no”模式，能够提供更好的性能（但如果你能接受一些数据丢失，可以考虑默认的持久化模式–快照方式），相反，使用“always”模式很慢，但是它比“everysec”模式要安全一点。
如果不确定，就使用“everysec”。
原文3：
When the AOF fsync policy is set to always or everysec, and a background saving process (a background save or AOF log background rewriting) is performing a lot of I/O against the disk, in some Linux configurations Redis may block too long on the fsync() call. Note that there is no fix for this currently, as even performing fsync in a different thread will block our synchronous write(2) call.
In order to mitigate this problem it’s possible to use the following option that will prevent fsync() from being called in the main process while a BGSAVE or BGREWRITEAOF is in progress.
This means that while another child is saving, the durability of Redis is the same as “appendfsync none”. In practical terms, this means that it is possible to lose up to 30 seconds of log in the worst scenario (with the default Linux settings).
If you have latency problems turn this to “yes”. Otherwise leave it as “no” that is the safest pick from the point of view of durability.
译文3：
当使用AOF的fsync方案设置为“always”或“everysec”时，后台的存储进程会执行大量的磁盘I/O操作，在一些Linux架构中，Redis在fsync()调用时可能会阻塞很久。这个问题当前并没有修复，即使是在一个不同的线程执行fsync也将会阻塞我们的同步写调用。
为了缓解这个问题，可以使用以下选项，它将会在有一个BGSAVE或BGREWRITEAOF正在运行时，阻止主进程调用fsync()。
这意味着有另一个子进程在存储时，Redis的持久性等同于“appendfsync none”。在实践中，意味着在最坏的情况下它可能丢失多达30秒的日志（默认的Linux设置）。
如果你有潜在的问题需要更改它为“yes”。否则从持久性的观点来看“no”是最安全的选择。
原文4：
Automatic rewrite of the append only file.
Redis is able to automatically rewrite the log file implicitly calling BGREWRITEAOF when the AOF log size grows by the specified percentage.
This is how it works: Redis remembers the size of the AOF file after the latest rewrite (if no rewrite has happened since the restart, the size of the AOF at startup is used).
This base size is compared to the current size. If the current size is bigger than the specified percentage, the rewrite is triggered. Also you need to specify a minimal size for the AOF file to be rewritten, this is useful to avoid rewriting the AOF file even if the percentage increase is reached but it is still pretty small.
Specify a percentage of zero in order to disable the automatic AOF rewrite feature.
译文4：
自动重写append only文件。
当AOF日志的大小根据指定的百分比增长时，Redis会暗中调用BGREWRITEAOF去自动重写日志文件。
工作原理：Redis记忆AOF文件最后一次重写的大小（如果重启后没有重写发生，AOF的大小在启动时会被使用）。
基本大小对比当前大小。如果当前大小比指定的百分比大，触发重写。并且你要为AOF文件指定一个最小的尺寸去重写，这对于避免重写AOF文件是有用的，即使达到了百分比增长率但它仍然是非常小的。
指定百分比为0以便禁用自动AOF重写。
原文5：
An AOF file may be found to be truncated at the end during the Redis startup process, when the AOF data gets loaded back into memory.
This may happen when the system where Redis is running crashes, especially when an ext4 filesystem is mounted without the data=ordered option (however this can’t happen when Redis itself crashes or aborts but the operating system still works correctly).
Redis can either exit with an error when this happens, or load as much data as possible (the default now) and start if the AOF file is found to be truncated at the end. The following option controls this behavior.
If aof-load-truncated is set to yes, a truncated AOF file is loaded and the Redis server starts emitting a log to inform the user of the event. Otherwise if the option is set to no, the server aborts with an error and refuses to start. When the option is set to no, the user requires to fix the AOF file using the “redis-check-aof” utility before to restart the server.
Note that if the AOF file will be found to be corrupted in the middle the server will still exit with an error. This option only applies when Redis will try to read more data from the AOF file but not enough bytes will be found.
译文5：
可能发现一个AOF文件在Redis启动过程中被截断，当AOF数据被加载回内存时。
这可能发生在系统中Redis运行崩溃，尤其是挂载一个EXT4文件系统而没有使用“data=ordered”选项时（但是这不会发生在Redis自身崩溃或中断而操作系统仍然正常运行的时候）。
当有一个错误发生时Redis要么退出，要么加载尽可能多的数据（当前默认）启动，如果AOF文件最后发现被截断。以下选项控制这个行为。
如果aof-load-truncated被设置为“yes”，一个被截断的AOF文件将会被加载，Redis服务启动发出一个日志告知用户这个事件。如果这个选项设置为“no”，服务器中止一个错误并拒绝启动。当选项被设置为“no”，用户需要在重启服务之前使用“redis-check-aof”功能确定AOF文件。
需要注意的是如果AOF文件被发现是损坏的，那服务器仍然会以一个错误退出。这个选项仅适用于Redis希望读取更多的数据但是没有发现足够的字节时。
二、RDB机制的优势和劣势
RDB存在哪些优势呢？
1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。
RDB又存在哪些劣势呢？
1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
三、AOF机制的优势和劣势
AOF的优势有哪些呢？
1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。
AOF的劣势有哪些呢？
1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。
2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
四、具体配置实现方式介绍
1. Snapshotting:
缺省情况下，Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
2. Dump快照的机制：
1). Redis先fork子进程。
2). 子进程将快照数据写入到临时RDB文件中。
3). 当子进程完成数据写入操作后，再用临时文件替换老的文件。
3. AOF文件：
上面已经多次讲过，RDB的快照定时dump机制无法保证很好的数据持久性。如果我们的应用确实非常关注此点，我们可以考虑使用Redis中的AOF机制。对于Redis服务器而言，其缺省的机制是RDB，如果需要使用AOF，则需要修改配置文件中的以下条目：
将appendonly no改为appendonly yes
从现在起，Redis在每一次接收到数据修改的命令之后，都会将其追加到AOF文件中。在Redis下一次重新启动时，需要加载AOF文件中的信息来构建最新的数据到内存中。
4. AOF的配置：
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。
5. 如何修复坏损的AOF文件：
1). 将现有已经坏损的AOF文件额外拷贝出来一份。
2). 执行"redis-check-aof --fix <filename>"命令来修复坏损的AOF文件。
3). 用修复后的AOF文件重新启动Redis服务器。
6. Redis的数据备份：
在Redis中我们可以通过copy的方式在线备份正在运行的Redis数据文件。这是因为RDB文件一旦被生成之后就不会再被修改。Redis每次都是将最新的数据dump到一个临时文件中，之后在利用rename函数原子性的将临时文件改名为原有的数据文件名。因此我们可以说，在任意时刻copy数据文件都是安全的和一致的。鉴于此，我们就可以通过创建cron job的方式定时备份Redis的数据文件，并将备份文件copy到安全的磁盘介质中。
五、内存型数据库Redis持久化小结
Redis可以通过创建快照来获得在内存里面的数据在某一个时间点上的副本。在创建快照之后，用户可以对快照进行备份，可以将快照复制到其它服务器从而创建具有相同数据的服务器副本，还可以将快照留在原地以便重启服务器时使用。
有两个命令可以用于生成RDB文件，一个是SAVE，另外一个BGSAVE。
在只使用快照持久化来保存数据时，如果系统真的发生崩溃，用户将丢失最近一次生成快照之后更改的所有数据。因此，快照持久化只适用于那些即使丢失一部分数据也不会造成问题的应用程序。
SAVE
特点：SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕，在服务器进程阻塞期间，服务器不能处理任何命令请求。
缺点：服务器持久化期间无法接受其它请求。
BGSAVE
特点：BGSAVE命令则会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程则继续处理命令请求。
缺点：创建子进程所耗费的时间会随着Redis占用的内存而增加。
AOF持久化
AOF持久化会将被执行的写命令写到AOF文件的末尾，以此来纪录数据所发生的变化，因此，Redis只要从头到尾重新执行一次AOF文件所包含的所有写命令，就可以恢复AOF文件所记录的数据集。
在设置同步频率的时候，存在三个选项：
| 选项 | 同步频率 |
|---|---|
| always | 每个Redis写命令都要同步写入硬盘，但是这样做会占用Redis所拥有的内存，严重降低Redis的速度 |
| everysec | 每秒执行一次同步，显式地将多个写命令同步到硬盘 |
| no | 让操作系统来决定应该何时进行同步 |
最好使用everysec，既能避免每次都写入所造成的性能影响，又能避免操作系统崩溃所导致的可能丢失不定量数据，其即使系统崩溃，用户最多只会丢失一秒之内产生的数据，当硬盘忙于执行写入操作的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
缺点：因为Redis会不断的将被执行的写命令纪录到AOF文件里面，所以随着Redis不断执行，AOF文件的体积也会不断增长，极端条件下，AOF甚至可能会用完硬盘的所有可用空间。
为了解决上面的缺点，Redis提供了BGREWRITEAOF命令，这个命令会通过移除AOF文件中的冗余命令来重写AOF文件，使得AOF文件尽可能的小。它的原理和BGSAVE命令相似，Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写，因为AOF文件重写也需要用到子进程，所以同样存在快照持久化因为创建子进程所导致的性能问题和内存占用问题。