Redis(十三) -- Redis配置(二) -- 持久化_redis 持久化配置

1. 方式一：RDB（Redis DataBase）

在指定的间隔时间内，将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存中

比如每隔10分钟，将现在redis的存储快照写到硬盘中去。

1.1 备份数据执行方式：

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

RDB的缺点：最后一持久化后的数据可能丢失。

1.2 关于fork

• Ford的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
• 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了：写时复制技术
• 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

1.3 rdb保存的文件：dump.rdb

在redis.conf配置文件中，默认名称为dump.conf
同时可以设置文件保存的位置

# 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 dump.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 ./
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

1.4 存储策略：

在多少秒内完成了多少次对redis的修改就进行保存；

比如如果设置了30秒内10个变化就存储，如果有12个key发生了变化，只会持久化前10个key

################################ 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 		# 900秒内一个key变化
save 300 10		# 300秒内10个key变化
save 60 10000	# 60秒内1万个key变化
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

1.5 手动保存：

我们也可以手动执行命令进行持久化写入操作：

• save：阻塞所有，只管保存快照，直到快照保存完成，线上环境不推荐这样
• bgsave：redis会在后台异步进行快照操作，快照同时还可以响应客户端请求，即上面说的是用fork进程执行，线上推荐
  • bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用

1.6 其他配置：

• stop-writes-on-bgsave-error yes：当Redis无法写入磁盘的话，直接关掉Redis的写操作
• rdbcompression yes：进行rdb保存时，将文件压缩
• rdbchecksum yes：在存储快照后，还可以让Redis使用CRC64算法来进行数
  据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能

1.7 rdb的恢复：

1. 关闭redis
2. 把rdb文件拷贝到工作目录下
3. 启动redis，备份数据会直接加载

1.8 优缺点：

• 优点：
  • 适合大规模的数据恢复
  • 对数据完整性和一致性要求不高
  • 节省磁盘空间
  • 恢复速度快
• 缺点：
  • Fork的时候，内存中的数据被复制了一份，大致2倍的膨胀性需要考虑
  • 虽然Fork在复制时使用了写时复制功能，但是数据庞大时还是比较消耗性能
  • 备份是每间隔一段时间做一次备份，如果redis意外down掉，会丢失最后一次备份后的所有修改

1.9 RDB的执行原理：

如图，redis是不能直接操作物理内存的，是有linux系统给每个进程分配一个虚拟内存，redis只能操作虚拟内存，redis会维护一个页表，用来记录虚拟地址与物理地址的映射，所以redis就能访问到物理内存。

上述的fork吃子进程其实是复制的页表，这样子进程也就有了映射关系。

如果写入的时候，主进程对数据进行了写入，这样不就出现了脏数据么？
在fork的过程中，会把全部数据设置为read-only，如果主进程需要进行写操作，会将具体数据拷贝一份出来，用于写入操作。接着，主进程进行读操作时，也是读取这份拷贝的数据。而子进程还是写入read-only的数据。

2. 方式二：AOF（Append Of File）

2.1 AOF是什么

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只可以追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就是根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

2.2 AOF持久化流程

1. 客户端的写操作会被append到aof的缓冲区
2. AOF缓冲区根据aof持久化策略（always、everysec、no）将操作sync同步到磁盘的aof文件中
3. aof文件大小超过设置的aof重写策略或者手动重写时，会进行aof文件重写，压缩文件大小
4. redis重启时，会加载aof文件中的写操作达到数据恢复的目的

2.3 默认不开启，需要在配置文件中手动开启

可以配置文件名称，默认为appendonly.aof

############################## 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.
# 改成yes
appendonly no

# The name of the append only file (default: "appendonly.aof")
# 生成默认文件
appendfilename "appendonly.aof"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

2.4 AOF文件故障备份和恢复：

• redis的备份与恢复：
  • AOF的备份机制和性能虽然和RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载
  • AOF和RDB同时开启，系统默认取AOF的数据
• AOF文件故障恢复
  • AOF的问卷保存路径和RDB一致
  • 如果AOF文件损坏，可通过：redis-check-aof --fix appendonly.aof 进行恢复
  • 恢复后再重启redis

2.5 AOF同步频率设置

• always：始终同步，每次Redis的写入都会立刻记入日志
• everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失
• no：不主动进行同步，把同步时机交给操作系统

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

# always：始终同步，每次Redis的写入都会立刻记入日志
# everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失
# no：不主动进行同步，把同步时机交给操作系统
# appendfsync always
appendfsync everysec
# appendfsync no
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

2.6 Rewrite压缩

2.6.1 是什么：

AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF的大小超过了所定的阙值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof

比如set a a；然后又执行了set a b；只会记录set a b。

2.6.2 重写原理，如何实现重写

AOF文件持续增长过大时，会fork出一条新进程来将文件重写（也是也写临时文件最后rename），redis4.0版本后的重写，是指就是把rdb的快照，以二进制的形式附在新aof的头部，作为已有的历史数据，替换掉原来的流水账操作

• no-appendfsync-on-rewrite=yes：不写入aof，只会写入缓存，用户请求不会阻塞，但是如果宕机会丢失宕机前这段时间的数据（降低数据安全，提高性能）
• =no：还是会把数据往aof中刷，但是遇到重写操作，会发生阻塞（提高数据安全，性能较低）

2.6.3 何时进行重写：

重写条件：Redis会记录上一次重写时AOF文件的大小，默认配置是当前AOF文件大小是：上次重写时文件大小+文件大小*100%且文件大于64M时触发

例：上次重写大小为size，则当前大小>= size+size*100%(设置值) 且当前大小>=64mb(设置值)的情况下，才会进行重写

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

注意：重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因为设定redis要满足一定条件才能进行重写

2.6.4 重写流程：

1. bgrewriteaof触发重写，判断当前是否有bgsave或bgrewriteaof在运行，如果有则等待该命令执行后再执行
2. 主进程fork出子进程执行重写操作，保证不阻塞主进程
3. 子进程遍历redis中数据到临时文件，客户端的写请求同时写入到aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原aof文件完整和新aof文件生成过程中不会有数据丢失
4. 子进程写完新的aof文件，向主进程发信号，父进程更新统计信息；主进程把aof_rewrite_buf中的数据写入到新的aof文件中
5. 使用新的aof文件覆盖旧的aof文件，完成重写

2.7 优缺点：

• 优点：
  • 备份机制更稳健，丢失数据概率更低
  • 可读的日志文本，通过操作AOF稳健，可以处理误操作
• 缺点：
  • 比起RDB占用更多的磁盘空间
  • 恢复备份速度更慢
  • 每次写都同步，有一定性能压力
  • 存在个别bug，造成无法恢复

3. RDB和AOF的抉择：两者都用默认使用AOF

• 官方推荐2个都用
• 如果对数据不敏感，可以单独用RDB
• 不建议单独用AOF，可能会有bug
• 如果只是做纯内存缓存，可以都不用