Redis-用的很溜，了解过它用的什么协议吗，阿里Java社招面试

本文链接：https://blog.csdn.net/m0_60732523/article/details/119518452

他说，事情是这样的，刚开始，问了一些基础的问题，比如 Redis 的几种基本数据类型和使用场景，以及主从复制和集群的一些问题，这些都还好。

然后问 Redis 的两种持久化方式，我说与 RDB 和 AOF 两种方式，RDB 数据文件小，恢复速度快，但是对性能有影响，而且不适合实时存储。而 AOF 是现在最常用的持久化方式，它的一大优点就是实时性，并且对 Redis 半身性能影响最小。

那面试又问了，你知道 AOF 持久化之后的文件是什么格式吗？

答：好像就是文本文件吧？

好，文本文件，那你知道它有什么规则吗？或者说，它和 Redis 的协议有什么关系吗？

答：啊，这个，恩，不太清楚呢。

现在就来看一下 AOF 和 RESP 协议的关系

从两种持久化方式说起。
RESP 协议是什么
动手实现一个简单的协议解析命令行工具

先从持久化说起，虽然一提到 Redis，首先想到的就是缓存，但是 Redis 不仅仅是缓存这么简单，它的定位是内存型数据库，可以存储多种类型的数据结构，还可以当做简单消息队列使用。既然是数据库，持久化功能是必不可少的。

Redis 的两种持久化方式

Redis 提供了两种持久化方式，一种是 RDB 方式，另外一种是 AOF 方式，AOF 是目前比较流行的持久化方案。

RDB 方式

RDB持久化是通过快照的方式，在指定的时间间隔内将内存中的数据集快照写入磁盘。它以一种紧凑压缩的二进制文件的形式出现。可以将快照复制到其他服务器以创建相同数据的服务器副本，或者在重启服务器后恢复数据。RDB是Redis默认的持久化方式，也是早期版本的必须方案。

RDB 由下面几个参数控制。

# 设置 dump 的文件名
dbfilename dump.rdb

# 持久化文件的存储目录
dir ./

# 900秒内，如果至少有1个key发生变化，就会自动触发bgsave命令创建快照
save 900 1

# 300秒内，如果至少有10个key发生变化，就会自动触发bgsave命令创建快照
save 300 10

# 60秒内，如果至少有10000个key发生变化，就会自动触发bgsave命令创建快照
save 60 10000

持久化流程

上面说到了配置文件中的几个触发持久化的机制，比如 900 秒、300秒、60秒，当然也可以手动执行命令 save或bgsave进行触发。bgsave是非阻塞版本，通过 fork 出子进程的方式来进行快照生成，而 save会阻塞主进程，不建议使用。

1、首先 bgsave命令触发；

2、父进程 fork 出一个子进程，这一步是比较重量级的操作，也是 RDB 方式性能不及 AOF 的一个重要原因；

3、父进程 fork 出子进程后就可以正常的相应客户端发来的其他命令了；

4、子进程开始进行持久化工作，对现有数据进行完整的快照存储；

5、子进程完成操作后，通知父进程；

RDB的优点:

RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中(如hdfs)，用于灾难恢复。
Redis加载RDB恢复数据远远快于AOF的方式。

RDB的缺点:

RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

AOF 方式

AOF 由下面几个参数控制。

# appendonly参数开启AOF持久化
appendonly yes

# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./

# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof出错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

针对RDB不适合实时持久化的问题，Redis提供了AOF 持久化方式来解决，AOF 也是目前最流程的持久化方式。

AOF（append only file），以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。

1、所有的写入命令会追加到aof_buf(缓冲区)中；

2、AOF缓冲区根据对应的策略向硬盘做同步操作；

3、随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的；

4、当Redis服务器重启时，可以加载AOF文件进行数据恢复；