Redis系列（二）持久化

引言

             持久化——将瞬时数据（存在不长久的数据）转化为持久数据（一直存在的数据）的一种机制。

概述         

             Redis也算是一种内存数据库，即它运行时的数据存放到内存中，所以性能较好。但是内存中的数据不能长久存在，一旦Redis重启，内存中的数据就不复存在，为了解决这一疑难，Redis支持持久化，Redis关闭后，数据会从内存持久化到硬盘中，当Redis重启再从硬盘将数据恢复到内存中。Redis包含俩种持久化机制RDB和AOF。

内容

              一 RDB（Redis DataBase）

             1 是什么？Redis以快照（snapshotting）的形式将内存的数据持久化到硬盘中。

             2 原理？

                    （1）Redis首先fork出一个子进程，该子进程用来将某一时刻的数据写入临时文件；

                    （2）子进程将数据写入临时文件完毕后，就将原来的RDB文件替换掉；

             3 怎么做？

                    （1）配置redis.conf文件中的snapshotting属性                     

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save  
#
#   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

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
#
# However if you have setup your proper monitoring of the Redis server
# and persistence, you may want to disable this feature so that Redis will
# continue to work as usual even if there are problems with disk,
# permissions, and so forth.
stop-writes-on-bgsave-error yes

# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
rdbchecksum yes

# The filename where to dump the DB
dbfilename dump6379.rdb

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

                    该配置文件中配置了创建快照的规则（save N M）以及文件名（dbfilename）和存储目录（dir ./）等规范。默认的save是save 900 1（900秒如果一个key值发生改变，就创建快照保存）；save 300 10；save 60 10000。当然save可以依据实际情况具体配置。

                   （2）创建快照

                            1）client执行save或bgsave命令，save为同步，bg为异步。一般情况下用bgsave，除非没有足够内存执行bgsave或者我们可以等待持久化操作完成的情况下，可以使用save命令。

                            2）Redis命令shutdown执行时，执行一次save命令，创建一次快照，阻塞所有客户端，并在save命令执行完毕关闭服务器。

                            3）当主服务器向从服务器发送sync命令，开始执行一次复制操作，若主服务器目前没有执行或者并非刚刚执行bgsave命令，主服务器就会执行bgsave命令。

                   （3）恢复

                            将文件（dump.rdb）移动到redis安装目录并启动服务即可。

             4 优劣势？

                   （1）优势

                           1）适合大规模的数据恢复

                           2）对数据完整性和一致性要求不高

                   （2）劣势

                           1）在一定时间间隔做持久化，如果redis意外down掉，就会丢失最后一次快照后的所有修改。

                           2）Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑，占用内存大量空间，降低性能。

              二 AOF（Append Only File）

             1 是什么？redis另外一种持久化方法，解决了RDB不完整性的缺陷。

             2 原理？将被执行的写命令写到AOF文件的末尾，以此来记录数据发生的变化，所以Redis重新执行一次AOF文件包含的所有命令，就可以恢复AOF文件持久化的数据集。

             3 怎么做？

                   （1）配置文件开启AOF持久化

                            redis.conf的APPEND ONLY MODE属性的appendonly no改为yes。

                   （2）重写机制（Rewrite）

                            1）提出背景：AOF文件体积不断增大，且导致还原操作执行的时间长。

                            2）原理：AOF文件持续增长而过大时，用户向redis发出bgrewriteaof命令，会fork出一条新进程将文件重写（先写临时文件最后在rename），便利新进程的内存中数据，每条记录有一条的Set语句，重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，和快照类似。

                            3）触发机制：Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发，通过设置redis.conf的APPEND ONLY MODE属性中auto-aof-rewrite-percentage和auto-aof-rewrite-min-size，来配置执行rewrite的参数和规则。

                   （3）恢复

                           1）正常恢复：将有数据的aof文件复制一份保存到对应目录（config get dir），重启redis即可。

                           2）异常恢复：拿到被写坏的aof文件，通过Redis-check-aof --fix进行修复，重启即可。

             4 优劣势？

                   （1）优势：

                           1）appendfsync always：同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。

                           2）appendfsync everysec：异步操作，每秒记录，如果一秒宕机有数据丢失。

                           3）appendfsync no：从不同步，由操作系统来决定应该何时对aof文件进行同步。

                                （2）劣势：

                           1）相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。

                           2）aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。

总结

            redis持久化方式如何来选择哪？RDB存在数据持久化丢失的缺陷，但是持久化性能很高，AOF可以解决数据丢失的缺陷，但是aof文件要远大于rdb文件，且aof运行效率较低。当然俩种方式可以同时使用也可以都不适用，具体选择哪种持久化方式需要根据用户的数据以及应用来定。