Redis 第一种持久化的方式RDB并不是非常耐久，如果 Redis 因为某些原因而造成故障停机，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。

AOF 机制是什么？

每当 Redis 执行一个改变数据集的命令时（比如 SET），这个命令就会被追加到 AOF 文件的末尾(默认是 appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
在这里插入图片描述

AOF 三种策略

Redis 操作的每条命令不是直接写入 AOF 文件的，而是保存在一个缓冲区域，根据三种策略里面的一种策略进行写入到AOF文件中：
在这里插入图片描述

每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全
每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据。
从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。

打开 redis.conf 配置文件：

# 新的命令马上执行到硬盘当中
# appendfsync always
# 每秒执行一次到硬盘中
appendfsync everysec
# 交给系统做决定，什么时候写入磁盘
# appendfsync no

推荐（并且也是默认）的措施为每秒 fsync 一次，这种 fsync 策略可以兼顾速度和安全性。

AOF 重写

因为 AOF 的运作方式是不断地将命令追加到文件的末尾，所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。举个例子，如果你对一个计数器调用了 100 次 INCR ，那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录（entry）。然而在实际上，只使用最后一条 SET 命令已经足以保存计数器的当前值了，其余 99 条记录实际上都是多余的。

为了处理这种情况， Redis 支持一种有趣的特性：可以在不打断服务客户端的情况下，对 AOF 文件进行重建（rebuild）。执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件，这个文件包含重建当前数据集所需的最少命令。Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令； Redis 2.4 则可以自动触发 AOF 重写，

在这里插入图片描述
有了AOF重写，我们就可以减少AOF文件的大小。当我们的机子宕机后，也可以迅速的进行恢复。

AOF 重写方式

BGREWRITEAOF
客户端执行重写的命令，类似RDB的bgsave。
如果客户端设置了密码，执行命令会出现没有授权，需要使用auth 授权

127.0.0.1:6379> bgrewriteaof
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

在这里插入图片描述

AOF 重写配置

配置命令	描述
auto-aof-rewrite-percentage	AOF文件增长率
auto-aof-rewrite-min-size	AOF重写文件的大小

例如打开 redis.conf 配置文件：
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
相当于我们AOF文件第一次达到64M，进行重写。这里我们定义的增长率为100%，那么第二次重写的时候，AOF 的文件需要达到128M 才会进行重写。

AOF 相关配置

打开redis.conf 配置文件

# 要使用AOF 功能需要将 值设置为 yes，默认为no
appendonly no
# AOF 文件名
appendfilename "appendonly-6379.aof"
# AOP 同步策略，这里使用 everysec
# appendfsync always
appendfsync everysec
# appendfsync no
# 保存RDB ,LOG,AOF 文件目录
dir /opt/redis/data/
# 该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题
# 如果设置为yes，这就相当于将appendfsync设置为no，就并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据
# 这里为了保存计算机的性能，我设置为yes
no-appendfsync-on-rewrite yes
# AOF 文件增长率
auto-aof-rewrite-percentage 100
# AOF 执行重写的大小
auto-aof-rewrite-min-size 64mb

AOF 优点

使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：无fsync,每秒fsync,每次写的时候fsync.使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
AOF 文件有序地保存了对数据库执行的所有写入操作，这些写入操作以 Redis 协议的格式保存，因此 AOF 文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。导出（export） AOF 文件也非常简单：举个例子，如果你不小心执行了 FLUSHALL 命令，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis ，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。

如何选择使用哪种持久化方式？

一般来说，如果想达到足以媲美 PostgreSQL 的数据安全性，你应该同时使用两种持久化功能。

如果你非常关心你的数据，但仍然可以承受数分钟以内的数据丢失，那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化，但我们并不推荐这种方式：因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快，除此之外，使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

之前准备学习的时候写博客，可是都没有坚持下去，希望这次可以有始有终。
Redis 坚持第一天：为什么要使用 redis ？
Redis 坚持第二天：Redis 的安装与启动
Redis 坚持第三天：Redis 使用配置文件启动，常见配置学习。
Redis 坚持第四天：

Redis 五种常见的数据结构：String

Redis 五种常见的数据结构：Hash

Redis 五种常见的数据结构：List

Redis 五种常见的数据结构：Set

Redis 五种常见的数据结构：zset

Redis 坚持第五天：Redis 客户端：Jredis 和 spring-data-redis 整合。
Redis 坚持第六天：Redis 慢查询日志。
Redis 坚持第七天：Redis pipeline。
Redis 坚持第八天：Redis 发布订阅。
Redis 坚持第九天：Redis bitmp。
Redis 坚持第十天：Redis HyperLogLogs。
Redis 坚持第十一天：Redis GEO。
Redis 坚持第十二天：Redis 持久化：RDB。
Redis 坚持第十三天：Redis 持久化：AOF。

Redis 持久化 ：AOF