Redis持久化

Redis作为目前最常用的键值对缓存数据库，因其具有访问速度快而备受欢迎，而其极快的访问速度是基于数据都在内存中来达到的。但是我们并不能保证redis服务一直正常，如果数据仅仅存储于内存中，那么意外的宕机就会导致数据丢失，所以Redis提供了数据持久化功能，目的就是将内存中的数据保存到磁盘上，同时也要最大可能的不影响读写操作的性能。

Redis提供了RDB(redis Database)和AOF(Append Only File)两种持久化方式，默认开启了RDB方式，该模式会在Redis启动后，自动生成dump.rdb文件，默认在redis-server命令的目录下。

下面我们详细的介绍一下这两种持久化方式。

RDB(redis Database)

在仅开启RDB模式的情况下，Redis启动时，会先加载dump.rdb文件，将磁盘快照加载到Redis内存中，默认会在redis-server所在目录下查找dump.rbd文件，而当我们再启动时指定了redis.conf文件，那么则使用redis.conf文件中配置的dir选项指定的dump.rdb文件路径。

RDB模式是将Redis内存中存储的数据全部以二进制的方式存储到磁盘上，就像是word文档的定时自动保存功能，防止数据丢失。

触发RDB持久化的方式很简单，大致有三种：

1:客户端发送save命令

当客户端向服务器发送save命令时，服务器会阻塞save命令只会的其他请求，直到数据同步完成。如果Redis内存中数据量太大，同步数据操作执行时间过长，而这期间Redis服务器会阻塞其他所有请求，所以，此命令和keys *命令一样，不能在生产环境使用

 2:客户端发送bgsave命令

bgsave命令和save命令功能一样，都是触发执行RDB持久化，不同的是当客户端发出bgsave命令时，Redis服务端会fork一个子进程来执行数据持久化，当内存中的数据全部持久化完成之后，子进程会自动退出。所以基于这种方式，主进程仍然可用继续接收其他请求，但是fork子进程的过程是同步的，也就是说在fork子进程的过程中，Redis服务器同样不能接收其他请求，所以如果fork子进程的过程耗费太长时间，仍然有阻塞其他客户端请求的情况发生

 3:服务端自动触发

Redis在redis.conf配置文件中通过save参数指定触发RDB持久化的条件，该方式和bgsave一样，会fork一个子进程执行RDB持久化，但是如果设置的触发时间太短，则容易频繁的写入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

save 900 1：900s内如果有至少1条写命令，则触发RDB持久化

save 300 10：300s内如果有至少10条写命令，则触发RDB持久化

save 60 10000：60s内如果有至少10000条写命令，则触发RDB持久化

save ""：关闭RDB持久化

AOF(Append Only File)

AOF方式在Redis中是默认未开启的，在开启AOF后，会将内容写入到appendonly.aof文件中，文件的内容是服务器接收到的所有对数据进行修改的命令集合，按照时间顺序追加到文件尾部，并且在故障恢复的时候，会优先读取appendonly.aof文件中的内容，因为aof的默认策略是每秒钟写入一次，所以当采用aof进行持久化的时候，最多也仅仅丢失一秒的数据。

配置信息：redis.conf文件中

随着服务运行时间越来越久，内存中的数据变更次数越来越多，会造成aof文件越来越大，当然我们可以在配置文件redis.conf中设置aof文件重写策略，默认当aof文件大小达到64mb且增长比例超过了之前是100%的时候进行重写，重写的规则是将内存中的数据的当前值全部以对应的set命令写入到新的aof文件中，比如当前aof文件100mb，重写之后80mb，那么只有当文件再次达到160mb(160>=80*2&&160>64)的时候才会再次进行重写。如果在AOF文件写入的过程中突然宕机，可能会导致aof文件损坏，我们可以使用redis-check-aof --fix命令来修复。

###### APPEND ONLY MODE ######
# 开启aof持久化
appendonly yes
# aof文件名称，存储位置在dir参数指定的文件夹内
appendfilename "appendonly.aof"

# appendfsync always # 每一次操作都做持久化
appendfsync everysec # 每一秒持久化一次
# appendfsync no # 不自动做持久化，手动触发

aof-load-truncated yes

aof-use-rdb-preamble yes

AOF重写

AOF是采用文件追加的方式做持久化，这就无法避免文件会越来越大，所以Redis针对于这种情况，提供了aof文件rewrite机制，当aof文件超过redis.conf中配置的情况时，就会自动触发rewrite操作，只保留同一个key的最近的一条指令记录，且默认在rewrite的时候暂停aof持久化，我们也可以使用指令bgrewriteaof手动的触发aof的rewrite。

# 在aof文件rewrite的时候不做持久化
no-appendfsync-on-rewrite no

# 自动rewrite的比例
auto-aof-rewrite-percentage 100
# 自动rewrite的文件最小大小
auto-aof-rewrite-min-size 64mb

但是rewrite之后，aof文件的内容和rdb文件的格式一样了

打开redis.conf配置文件

# When rewriting the AOF file, Redis is able to use an RDB preamble in the
# AOF file for faster rewrites and recoveries. When this option is turned
# on the rewritten AOF file is composed of two different stanzas:
#
#   [RDB file][AOF tail]
#
# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
aof-use-rdb-preamble yes

AOF在重写的时候，会使用优先RDB文件进行快速rewrite。那么如果我们想要AOF仍然保持指令级的重写，只需要将参数aof-use-rdb-preamble修改为no即可

两种方式的对比的优缺点

优点

RDB: 1:恢复备份速度快   2:最新全量数据备份,文件体积小,占用磁盘小 3:备份过程由子进程进行，对Redis主进程影响较小

AOF: 1:备份频繁，数据丢失的概率低   2: 文件内容可读性较高

缺点

RDB: 1:备份频率低，数据丢失概率高  2:使用不当会引起redis主进程阻塞  3: 数据量过大时，fork子进程也会发生阻塞  4: 子进程在执行过程中会耗费过多内存

AOF: 1:文件体积较大，占用磁盘空间较多 2:恢复数据速度慢 3:文件易损坏

转自:https://blog.csdn.net/luxiaoruo/article/details/107033291