redis持久化

Redis provides a different range of persistence options:

• The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
• the AOF persistence logs every write operation received by the server, that will be played again at server startup, reconstructing the original dataset. Commands are logged using the same format as the Redis protocol itself, in an append-only fashion. Redis is able to rewrite the log on background when it gets too big

上面这段话节选自redis官网，可知redis持久化有两种方式：RDB和AOF。接下来一一介绍。

RDB （Redis DataBase）

有上面摘要可知：RDB就是在指定时间间隔内把内存中的数据集快照写入磁盘，也就是Snapshots。需要恢复数据就是将快照读取到内存。

这种方式Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到。一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件（dump.rdb）

优点：因为是fork一个子进程来工作，不影响主进程读写确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性（看缺点，最后一次数据可能丢失）不是非常敏感，那RDB方式要比AOF方式更加的高效，更快。

缺点：最后一次持久化后的数据可能丢失。因为上次保存后，下次还没保存可能突然宕机，那么上次到宕机这段时间数据就没了。此外，fork操作拷贝一个子进程，也会耗费资源。Fork()可能很耗时，如果数据集很大，CPU性能不太好，则可能导致Redis在几毫秒甚至一秒钟内停止为客户端提供服务。

下面是关于redis.conf关于RDB的配置

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

由配置可知，只要满足以上的三种情况中一种都会触发RDB持久化操作，900s内（15分钟）改动至少一次、300s（5分钟）内改动至少10次和60s（1分钟）修改至少一万次。

实验演示：

修改下配置演示这个功能 save 60 5，这样做实验比较方便，一分钟修改5次就触发，记得先把原有src目录下的dump.rdb删除或者重命名。重启服务，然后进行修改，这里设置了6个值。

1分钟过去就会发现重新生成dump.rdb。把这个文件先转移到机子。然后清空数据库

会发现数据没了，flushall这类提交命令，会导致本机的rdb文件也会改变，所以无法用现在本机的rdb进行恢复，接下来我们把先前的dump.rdb（存有flushall之前的数据）放回redis的安装目录重启服务，数据恢复。

可以用显示命令 save 或bgsave也会重新生成dump.rdb。二者区别：

save会阻塞其他请求。bgsave在后台异步进行，不会阻塞其他客户端请求。

AOF(Append Only File)

这种持久化将每个写操作以日志方式记录下来（appendonly.aof），忽略读操作。redis重启时根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

############################## APPEND ONLY MODE ###############################

# 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.
#
# Please check http://redis.io/topics/persistence for more information.

appendonly no

由redis.conf可知默认情况是关闭的，因为绝大部分情况rdb方式足够了。 

实验演示：

将配置appendonly改成yes。启动服务会发现生成appendonly.aof。为了避免干扰可以先将dump.rdb删除

进行上述操作 然后查看appendonly.aof文件

有点不同但可以看出就是记录写操作，把flushall删除，然后重启

发现数据恢复，说明就是把appendonly.aof文件重头执行了一遍进行数据恢复。

我们再对appendonly.aof进行内容破坏，让redis无法识别

重启发现服务起不来

这说明rdb和aof同时开启的时候，aof优先，所以先去加载aof文件，因为文件格式问题服务起不起来。可以按照提示用redis-check-aof进行恢复。

实验结束

看看对应配置

# 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.
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# If unsure, use "everysec".

# appendfsync always
appendfsync everysec
# appendfsync no

always：每次发生数据变更会被立即记录到磁盘  性能较差但数据完整性比较好

everysec：每秒同步，出厂默认推荐，异步操作，每秒记录   如果一秒内宕机，有数据丢失，最多不丢超过两秒的数据

appendfsync no：从不同步

AOF有一个问题就是大量的读操作写入会使文件很大，所以有对应的重写机制。当文件大小超过对应阈值，就会对文件内容进行压缩。原理是fork出一条子进程将文件重写，并没有读取旧的AOF文件，而是遍历新进程中的内存数据，用命令方式写个临时文件再重命名回去覆盖。所以其实重写和原本的aof文件无关。

这里存在一个问题，就是fork出一条子进程（拷贝了原有的数据），但是新的客户端请求可能对现有的数据进行修改，这会让当前数据库的数据和重写后的AOF文件中的数据不一致。如何解决？

父类将所有新更改累积到内存缓冲区中(但同时它将新更改写入旧的仅追加文件中，因此如果重写失败，则是安全的)。当子进程重写完文件后，父进程会收到一个信号，并在子进程生成的文件末尾追加内存缓冲区（此时产生的阻塞不可避免，因此尽量减少重写），然后再重命名回去覆盖

何时触发？

默认配置是当大小达到上次重写的大小一倍并且超过64M。

# 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.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

 一般是要改成5G左右。Redis也支持BGREWRITEAOF命令显示触发重写。

AOF在数据完整性上优于RDB，可以设置多种同步策略，根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。其实二者就是完整性和效率的权衡。

讲到这，我还是推荐大家去看官网，因为讲的好清楚，逃。。。。。