2021-03-10

目录

一、Redis的AOF是什么？

二、Redis配置文件redis.conf中关于AOF相关配置

1.默认AOF没有开启

2.默认名称

3.三种appendfsysnc：同步策略

三：重写（rewrite）（查看Linux服务器命令-free内存， df磁盘），时间换空间的思想在里面！

1.重写是什么？

2.重写原理

3.触发机制

四、RDB和AOF持久化的区别

五、RDB和AOF两种持久化方式怎么选择？

---

一、Redis的AOF是什么？

官网-AOF中文：http://www.redis.cn/topics/persistence.html

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

二、Redis配置文件redis.conf中关于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.

appendonly no

# The name of the append only file (default: "appendonly.aof")

appendfilename "appendonly.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

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

# 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

# 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

1.默认AOF没有开启

appendonly no #如果要开启，改为yes

启动：修改为yes，启动

修复：使用redis-check-aof --fix 进行修复

恢复：重启redis然后重新加载

2.默认名称

appendonlyfilename appendonly.aof

3.三种appendfsysnc：同步策略

# appendfsync always：同步持久化，每次发生数据变更立即记录到磁盘，基本上不丢失数据 ，性能较差到数据完整性比较好

appendfsync everysec：出厂默认推荐，异步同步，每秒记录一次，性能和数据的完整性适中

# appendfsync no：操作系统控制写回，操作系统决定何时将缓存区的数据写回磁盘，性能比 较好，但是数据的完整性比较差

三：重写（rewrite）（查看Linux服务器命令-free内存， df磁盘），时间换空间的思想在里面！

 

1.重写是什么？

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

2.重写原理

（1）AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)

（2）复制缓冲，将AOF的缓冲数据拷贝到AOF重写缓冲中，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件

（3）如果redis主线程有新的操作，则该操作会写入AOF缓冲和AOF重写缓冲，这样就会保证AOF重写缓冲中数据是最新最全的数据

3.触发机制

#Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。默认64M。 #配置： auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

四、RDB和AOF持久化的区别

RDB 持久化	AOF 持久化
全量备份，一次保存整个数据 库。	增量备份，一次保存一个修改数据 库的命令。
保存的间隔较长。	保存的间隔默认为一秒钟。
数据还原速度快。	数据还原速度一般。冗余命令越多， 还原速度越慢。
执行 SAVE 命令时会阻塞服务器，但手动或者 自动触发的 BGSAVE 都不会阻塞服务器。	无论是平时还是进行 AOF 重写时，都不会阻塞服务器。
更适合数据备份。	更适合用来保存数据，通常意 义上的数据持久化。 在 appendfsync always 模式下运行时，Redis 的持久 化方式和一般的 SQL 数据库的持久化方式是一样 的。

五、RDB和AOF两种持久化方式怎么选择？

官网：http://www.redis.cn/topics/persistence.html

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。

只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

同时开启两种持久化方式

--在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,

因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

--RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？

作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，

快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

2.性能建议

• 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
• 如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
• 如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构