Redis 配置数据持久化

1、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但愿读取更多的数据可是没有发现足够的字节时。

 

2、RDB机制的优点和劣势

   RDB存在哪些优点呢？

    1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是很是完美的。好比，你可能打算每一个小时归档一次最近24小时的数据，同时还要天天归档一次最近30天的数据。经过这样的备份策略，一旦系统出现灾难性故障，咱们能够很是容易的进行恢复。
    2). 对于灾难恢复而言，RDB是很是不错的选择。由于咱们能够很是轻松的将一个单独的文件压缩后再转移到其它存储介质上。
    3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它惟一须要作的只是fork出子进程，以后再由子进程完成这些持久化的工做，这样就能够极大的避免服务进程执行IO操做了。
    4). 相比于AOF机制，若是数据集很大，RDB的启动效率会更高。
   
   RDB又存在哪些劣势呢？

    1). 若是你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。由于系统一旦在定时持久化以前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
    2). 因为RDB是经过fork子进程来协助完成数据持久化工做的，所以，若是当数据集较大时，可能会致使整个服务器中止服务几百毫秒，甚至是1秒钟。

   
3、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同样高效。

4、具体配置实现方式介绍

   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到安全的磁盘介质中。 

 

5、内存型数据库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文件重写也须要用到子进程，因此一样存在快照持久化由于建立子进程所致使的性能问题和内存占用问题。