redis持久化之AOF

一：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内存回收策略：

　　Redis中提供了多种内存回收策略，当内存容量不足时，为了保证程序的运行，这时就不得不淘汰内存中的一些对象，释放这些对象占用的空间，那么选择淘汰哪些对象呢？其中，默认的策略为noeviction策略，当内存使用达到阈值的时候，所有引起申请内存的命令会报错。

　　allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰适合的场景： 如果我们的应用对缓存的访问都是相对热点数据，那么可以选择这个策略

　　allkeys-random：随机移除某个key。适合的场景：如果我们的应用对于缓存key的访问概率相等，则可以使用这个策略

　　volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰。

　　volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。

　　volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的

Redis是单进程单线程？性能为什么这么快：

　　Redis采用了一种非常简单的做法，单线程来处理来自所有客户端的并发请求，Redis把任务封闭在一个线程中从而避免了线程安全问题；redis为什么是单线程？官方的解释是，CPU并不是Redis的瓶颈所在，Redis的瓶颈主要在机器的内存和网络的带宽。那么Redis能不能处理高并发请求呢？当然是可以的，至于怎么实现的，我们来具体了解一下。 【注意并发不等于并行，并发性I/O流，意味着能够让一个计算单元来处理来自多个客户端的流请求。并行性，意味着服务器能够同时执行几个事情，具有多个计算单元】

　　多路复用：

　　Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的。

　　先简单了解下几种I/O模型

（1）同步阻塞IO（Blocking IO）：即传统的IO模型。

（2）同步非阻塞IO（Non-blocking IO）：默认创建的socket都是阻塞的，非阻塞IO要求socket被设置为NONBLOCK。

（3）IO多路复用（IO Multiplexing）：即经典的Reactor设计模式，也称为异步阻塞IO，Java中的Selector和Linux中的epoll都是这种模型。

（4）异步IO（Asynchronous IO）：即经典的Proactor设计模式，也称为异步非阻塞IO。

　　同步和异步，指的是用户线程和内核的交互方式，阻塞和非阻塞，指用户线程调用内核IO操作的方式是阻塞还是非阻塞就像在Java中使用多线程做异步处理的概念，通过多线程去执行一个流程，主线程可以不用等待。而阻塞和非阻塞我们可以理解为假如在同步流程或者异步流程中做IO操作，如果缓冲区数据还没准备好，IO的这个过程会阻塞。