档案局网站的建设/seo值怎么提高

Redis 持久化RDB与AOF（一） ：RDB

1、介绍

AOF（append only file）是以将执行过的命令（只包含对元素有修改的命令）追加记录到文件中，当redis重启时将这个文件中的命令全部执行来达到恢复数据到内存效果。

2、AOF持久化方式

AOF持久化方式默认是不开启的，我们需要修改配置文件。

2.1、配置文件

我们要开启 aof，将 appendonly值改为yes。

############################## APPEND ONLY MODE ###############################
# 开启aof功能，默认为no
appendonly yes

2.2、AOF文件介绍

aof文件里面记录的是执行过的写命令（更新元素的命令）

2.2.1、配置aof生成的位置

# 存放记录追加命令的文件名，一般建议不要修改
appendfilename "appendonly.aof"

2.2.2、修复aof文件

当aof文件出现问题时我们可以通过自带的修复工具修复大部分数据

 redis-check-aof --fix 你的aof文件 

2.2.3、追加操作命令的规则

appendfsync 配置项可以配置如何去保存追加的命令。

# 追加命令到文件的策略: 
# always 同步持久化，发生变化立马记录到磁盘，数据完整但效率较差
# everysec 异步持久化，每秒记录，如果redis挂掉可能会丢失数据
# no 不同步
appendfsync everysec

3、重写机制

3.1、重写基本介绍

由于这个文件一直记录着写的命令，因此这个文件肯定会非常大。这时候重写机制的用处就来了。
原appendonly.aof 文件内容如下：

set key1 1
incr key1
incr key1
incr key1

重写过后：

set key1 5

好处显而易见。我们可以配置什么时候去重读，频繁的重读也是不好的，他也需要Fork（类似服务）一个子进程去读内存中的数据，然后以现在的数据生成命令，例如你现在库中 key1的值是5，那么他就会生成 set key1 5 这个命令，而不会去管怎么来到5的。并且在重写的过程中并没有读取旧的 appendonly.aof 文件。

3.2、设置触发条件

下面两个参数表达了，当前的 appendonly.aof 文件是上次的两倍大小并且大于64M时执行重写。

auto-aof-rewrite-percentage 100  # 文件大小是上次的多少倍，100为两倍
auto-aof-rewrite-min-size 64mb   # 文件大小大于多少时，这里为64MB 正式环境肯定是几个G

3.3、主动触发命令

bgrewriteaof  # 主动触发重写操作

4、优势

丢失数据少，执行过的命令会被记录，不像RDB方式一样需要等待条件的达成才开始执行持久化。

5、劣势

1、aof的文件远远要比rdb文件大，重启redis后恢复数据的速度也会比rdb慢，以为他要一行行命令执行。
2、持久IO操作
3、重写操作进行时，如果有新数据写入进来会造成阻塞。应该尽量减少重写的频率，基础大小 64MB太小了，应该设置大一些