Redis的RDB和AOF两种存储方式

绝地灬酷狼 2022-05-19 00:26 118阅读 0赞

Redis其实就是一个用C语言写的一个程序，这个程序用来存储 key-value数据，数据先放在内存，然后写入磁盘指定位置。

这么理解十分肤浅，但tm好像就是这样啊。

下面我们梳理一下Redis存储两种方式： RDB和AOF

第一种方式：RDB(Redis DataBase)

RDB是将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。

在Redis中，默认开启RDB方式进行数据存储，redis.conf中的**具体配置参数如下**；

\#dbfilename：持久化数据存储在本地的文件

dbfilename dump.rdb （dump.rdb为存储的文件名，redis通过io流将内存中的数据，写入该文档）

\#dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下

dir ./

\#save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key时间隔300s进行存储；更改10000个key时间隔60s进行存储。

save 900 1

save 300 10

save 60 10000

这里我们可以继续添加，也可以修改参数   比如 save 10 10000  10000个数据时间间隔10s就持久化

使用命令进行持久化save存储：

./redis-cli -h ip -p port save      ./redis-cli -h ip 127.0.0.1 -p 6379 save

./redis-cli -h ip -p port bgsave         ./redis-cli -h ip 127.0.0.1 -p 6379 bgsave

一个是在前台进行存储，一个是在后台进行存储。我的client就在server这台服务器上，所以不需要连其他机器，直接./redis-cli bgsave.

持久化过程：

当满足save的条件时，比如更改了1个key，900s后会将数据写入临时文件，持久化完成后将临时文件替换旧的dump.rdb。（存储数据的节点是到触发时间时的的节点，也就是对Key有个计数）

使用RDB恢复数据：

自动的持久化数据存储到dump.rdb后。实际只要重启redis服务即可完成（启动redis的server时会从dump.rdb中先同步数据），所以说当我们在关停redis服务的时候，只需要在/redis-3.2.12/src目录下查看是否存在dump.rdb，如果存在，则下次启动redis服务的时候，数据会由redis自动恢复。（如果不存在，那一定是配置文件 redis.conf出了错）

接上篇博客，我的RDB方式配置如下：

![70][]

![70 1][]

![70 2][]

我的RDB 的dump.rdb存放在/var/redis/data目录下面的

第二种方式：AOF（appendonly file)

AOF是将执行过的指令记录下来，数据恢复时按照从前到后的顺序再将指令执行一遍，实现数据恢复。

其中，AOF默认关闭，开启方法，修改配置文件redis.conf：appendonly yes

其他相关配置项：

\#AOF保存的文件名

appendfilename "appendonly.aof"   (将执行的指令记录在appendonly.aof文件中）

**以下为同步方式相关的配置：**

\#一旦插入命令，立即同步到磁盘，保证了完全的持久化，但是速度慢，且浪费Redis的性能，不推荐

appendfsync always

\#AOF每秒进行同步

appendfsync everysec

\#不自动同步，性能最好，但是持久化没有保证

appendfsync no

在此必须说明，fsync是一个命令，在大多数的Linux系统下，每30s就会执行一次fsync，将数据持久化到磁盘，所以这里的appendfsync no其实是交给linux服务器，30s就持久化一次数据；另外，appendfsync everysec  每秒就持久化一次数据，如果数据量在这1s里面非常大呢，redis是持久化不过来的，那么redis就采取的是延迟持久化，会在2s后继续持久化未持久化完成的数据，在appendfsync everysec 每秒持久化的情况下，会造成写阻塞，所以会导致redis存储的数据丢失，这时候就必须采用分布式，让多台redis服务去处理。（由此可以看见，redis存储虽然很强大，但也不是完美无缺的）

存储过程：将快照内容以命令的形式追加到AOF文件中，所以随着追加AOF文件会越来越大

保存的AOF文件存储了执行的所有命令，所以可以进行修改文件来撤销输错的命令（在重写之前，如果重写了就没有办法了）

针对AOF文件越来越大的问题，可以对AOF文件进行**重写**，命令如下：

redis-cli -h ip -p port bgrewriteaof      ./redis-cli -h 127.0.0.1 -p 6379 bgrewriteaof

重写命令的操作过程：在当前的快照保存工作结束后，开启一个子进程，将AOF文件进行重写，合并set命令等操作到一个临时文件，达到缩小文件大小的目的。重写结束后后将临时文件替换为新的AOF文件（重写过程中如果有新的redis操作命令，会提交到缓存中，重写结束后追加到AOF文件内）

说明：redis2.4以上版本，重写机制自动触发。触发的相关redis.conf配置如下：

auto-aof-rewrite-percentage 100（当目前的AOF文件大小超过上一次重写文件大小的百分之几时进行重写，如果没有重启过，则以启动时的AOF文件大小为依据）；

auto-aof-rewrite-min-size 64mb（允许重写的最小AOF文件大小）；

数据恢复：

重启redis服务，前提是配置文件必须设置了appendonly yes，然后会从appendfile的文件加载文件。反之是从RDB中加载数据的。

cluster集群的配置，使用的存储方式就必须是AOF方式。

从appendfile加载数据：我们先来看一下appendfile的内容是什么。下面的一条记录摘取自appendfile：SET $9 olylakers $3 oly。很显，appendfile保存的就是redis server接收到的各种命令，那么从appendfile加载数据就是redis server从appenfile里面读取这些命令的记录，然后重新把这些命令执行一遍即可。需要注意的是，如果开启了VM，那么在从appendfile加载数据的时候可能要涉及swap操作。

从redisdb加载数据：如果没有开启appendonly，那么则需要从db file加载数据到内存，其过程是：

1.通过处理select命令，选择DB

2.然后从db file读取key和value

3.检查key是否过期，如果过期则跳过这个key，如果不过期，则把数据Add到对应的db的dict中

4.如果开启了VM，则从db file中load数据，也可能涉及到swap操作

![70 3][]

![70 4][]

![70 5][]

![70 6][]

![70 7][]![70 8][]

总结：RDB存储是默认的存储方式，小数量，不在乎是否有并发，数据是否会丢失，安全性最好，占用的空间也最小。AOF方式在分布式下，可应对大量数据处理问题，但也会存在数据丢失。

本来第一次编辑得还可以看，但是Csdn尿性瞬间崩溃了，所以这篇博客，排版啥的几乎没有，望见谅！！！

[70]: /images/20220519/513c4ef5b8da4a77ab382b7339a91b29.png
[70 1]: /images/20220519/c40b47fa672c470b88971ee46a771d27.png
[70 2]: /images/20220519/c3e20f82fdd4446cabe043fa4fd2e0f2.png
[70 3]: /images/20220519/f9c0cec63fb549b4be3ad6bd5dcd981b.png
[70 4]: /images/20220519/835df52fbef04d4793c444cbf15d12bf.png
[70 5]: /images/20220519/3cda259b233247a497ed8c6555356d6b.png
[70 6]: /images/20220519/3d6c0176652d4701bfafd4e16d367e18.png
[70 7]: https://img-blog.csdn.net/20180719213153319?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MjY4MzY3OQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 8]: /images/20220519/526495239c5544798b1baf9640c862ac.png