redis持久化之AOF

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了redis持久化之AOF，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含11238字，纯文字阅读大概需要17分钟。

内容图文

一：Redis的AOF是什么？

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

　　RDB可以搞定备份恢复的事情，为什么还会出现AOF？

　　　　使用RDB进行保存时候，如果Redis服务器发送故障，那么会丢失最后一次备份的数据！AOF出现试着来解决这个问题！

　　同时出现RDB和AOF是冲突呢？还是协作？

　　　　是协作，但是首先启动找的是aof。

　　当redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存：

　　　　如果只配置AOF,重启时加载AOF文件恢复数据；

　　　　如果同时 配置了RBD和AOF,启动是只加载AOF文件恢复数据;

　　　　如果只配置RBD,启动是加载RDB文件恢复数据。

　　　　恢复时需要注意，要是主库挂了不能直接重启主库，否则会直接覆盖掉从库的AOF文件，一定要确保要恢复的文件都正确才能启动，否则会冲掉原来的文件。

二：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.
#默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。
但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化，
Append Only File是另一种持久化方式，可以提供更好的持久化特性。
Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，
每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件
appendonly no #如果要开启，改为yes
# The name of the append only file (default: "appendonly.aof")
# 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
#aof持久化策略的配置
#no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
#always表示每次写入都执行fsync，以保证数据同步到磁盘。
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。
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.
# 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，
执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。
如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，
这样对持久化特性来说这是更安全的选择。设置为yes表示rewrite期间对新写操作不fsync,
暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。
可能丢失30秒数据。随着aof文件持续增大，会fork出一条进程去对aof文件重写
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.
#aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，
即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。
当前AOF文件大小是上次日志重写得到AOF文件大小的一倍（设置为100）时，
自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写
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文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。
重启可能发生在redis所在的主机操作系统宕机后，
尤其在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会造成尾部不完整现象。）
出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，
当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，
用户必须手动redis-check-aof修复AOF文件才可以。
aof-load-truncated yes
# 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.
#
# This is currently turned off by default in order to avoid the surprise
# of a format change, but will at some point be used as the default.
#Redis4.0新增RDB-AOF混合持久化格式，在开启了这个功能之后，
AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容，
其中RDB格式的内容用于记录已有的数据，而AOF格式的内存则用于记录最近发生了变化的数据，
这样Redis就可以同时兼有RDB持久化和AOF持久化的优点（既能够快速地生成重写文件，
也能够在出现问题时，快速地载入数据）。
aof-use-rdb-preamble no

　　注：当 aof 文件损坏的时候 可以使用修复：使用redis-check-aof –fix xxx.aof 进行修复 同理 rdb文件也有专门的修复redis-check-dump

　　aof 文件重写： AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

三：小结 

　　　　　 AOF 文件是一个只进行追加的日志文件
　　　　　  Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写
　　　　　  AOF文件有序地保存了对数据库执行所有写入操作，这些写入操作作为redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松
　　　　　  对于相同的数据集来说，AOF文件的体积通常大于RDB文件的体积，根据所使用的fsync策略，AOF的速度可能会慢于RDB

1：到底启用哪种持久化策略？
　　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文件，载入较新的那个。新浪微博就选用了这种架构

内容总结

以上是互联网集市为您收集整理的redis持久化之AOF全部内容，希望文章能够帮你解决redis持久化之AOF所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---