Redis基础知识(学习笔记17--持久化 (3))

3.4 参数优化

(1)appendfsync

# 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

当客户端提交写命令后,该命令就会写入到aof_buf中,而aof_buf中的数据持久化到磁盘AOF文件的过程称为数据同步。

何时将aof_buf中的数据同步到AOF文件?采用不同的数据同步策略,同步的时机是不同的,有三种策略:

  • alwasy:写操作命令写入aof_buf后会立即调用fsync()系统函数,将其追加到AOF文件。该策略效率较低,但是相对较安全,不会丢失太多数据。最多就是刚刚执行过的写操作在尚未同步时出现宕机或重启,将这一操作丢失。
  • no:写操作命令写入aof_buf后什么也不做,不会调用fsync()函数。而将aof_buf中的数据同步到磁盘的操作由操作系统负责。Linux系统默认同步周期为30秒。效率较高。
  • everysec:默认策略。写操作命令写入aof_buf后并不直接调用fsync(),而是每秒调用一次fsync()系统函数来完成同步。该策略兼顾到了性能与安全,是一种折中方案。

(2)no-appendfsync-on-rewrite

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

no-appendfsync-on-rewrite no

 该属性用于指定,当AOF fsync策略设置为always 或 everysec,当主进程创建了子进程正在执行bgsave或bgrewriteaof时,主进程是否不调用fsync()来做数据同步。设置为no,双重否定即肯定,主进程会调用fsync()做同步。而yes则不会调用fsync()做数据同步。

如果调用了fsync(),在需要同步的数据量非常大时,会阻塞主进程对外提供服务,即会存在延迟问题。如果不调用fsync(),则AOF fsync策略相当于设置为了no,可能会存在高达30秒日志的丢失。

(3)aof-rewrite-incremental-fsync 和 rdb-save-incremental-fsync

注意:这一步的定义在【########## ADVANCED CONFIG #######】部分

# When a child rewrites the AOF file, if the following option is enabled
# the file will be fsync-ed every 4 MB of data generated. This is useful
# in order to commit the file to the disk more incrementally and avoid
# big latency【延迟】 spikes【尖刺】.
aof-rewrite-incremental-fsync yes

# When redis saves RDB file, if the following option is enabled
# the file will be fsync-ed every 4 MB of data generated. This is useful
# in order to commit the file to the disk more incrementally and avoid
# big latency spikes.
rdb-save-incremental-fsync yes

当bgrewriteaof在执行过程中也是先将rewrite计算的结果写入到了aof_rewrite_buf缓存中,然后当缓存中数据达到一定量后,就会调用fsync()进行刷盘操作,即数据同步,将数据写入到临时文件。该属性用于控制fsync()每次刷盘的数据量最大不超过4MB。这样可以避免由于单次刷盘量过大而引发长时间阻塞。

(4)aof-load-truncated

# 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.
aof-load-truncated yes

(5)aof-timestamp-enabled

# Redis supports recording timestamp annotations【注解】 in the AOF to support restoring # the data from a specific point-in-time. However, using this capability changes # the AOF format in a way that may not be compatible【兼容的】 with existing AOF parsers.【当前的AOF解析器】 aof-timestamp-enabled no

该属性设置为yes则会开启在AOF文件中增加时间戳的显示功能,可方便按照时间对数据进行恢复。但该方式可能会与AOF解析器不兼容,所以默认值为no,不开启。

3.5 AOF持久化过程

AOF详细的持久化过程如下:

1)Redis接受到写操作命令并不是直接追加到磁盘的AOF文件的,而是将每一条写命令按照redis通讯协议格式暂时添加到AOF缓冲区aof_buf。

2)根据设置的数据同步策略,当同步条件满足时,再将缓冲区中的数据一次性写入磁盘的AOF文件,以减少磁盘IO次数,提高性能。

3)当磁盘的AOF文件大小达到rewrite条件时,redis-server主进程会fork出一个子进程bgwriteaof,由该子进程完成rewrite过程。

4)子进程bgwriteaof首先对磁盘AOF文件进行rewrite计算,将计算结果写入到一个临时文件,全部写入完毕后,再rename该临时文件为磁盘文件的原名称,覆盖原文件。

5)如果在rewrite过程中又有写操作命令写入到临时文件后,那么这些数据会暂时写入aof_rewrite_buf缓冲区。等将全部rewrite计算结果写入临时文件后,会先将aof_rewrite_buf缓冲区中的数据写入临时文件,然后再rename为磁盘文件的原名称,覆盖原文件。

概况如下:

  

 四. RDB 与 AOF 对比

4.4.1 RDB优势与不足

(1)RDB优势

  • RDB文件较小(内存数据);
  • 数据恢复较快。

(2)RDB不足

  • 在一次性写入量较大的情况下,数据丢失风险较大;持久化过程相对较长,较重的磁盘IO;因此数据持久性相对差;
  • 写时复制会降低性能;
  • RDB文件可读性较差。

4.4.2 AOF优势与不足

(1)AOF优势

  • 数据及时持久性强(数据丢失的可能性小);
  • AOF文件可读性强。

(2)AOF不足

  • AOF文件相对较大(日志型);
  • 写操作会影响性能;
  • 数据恢复相对慢。

4.4.3 持久化技术的选型

  • 官方推荐使用RDB与AOF混合式持久化。
  • 若对数据持久性要求不高,则推荐使用纯RDB持久化方式。
  • 官方不推荐使用纯AOF持久化方式(文件大;恢复慢)。
  • 若Redis仅用于缓存,则无需使用任何持久化技术。

 

学习参阅特别声明

【Redis视频从入门到高级】

【https://www.bilibili.com/video/BV1U24y1y7jF?p=11&vd_source=0e347fbc6c2b049143afaa5a15abfc1c】

热门相关:老婆的姐姐   农家小地主   童养媳之桃李满天下   名门极致宠妻   腹黑boss霸宠:逃妻,吻我