他说,事情是这样的,刚开始,问了一些基础的问题,比如 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文件进行数据恢复;
AOF 文件里存的是什么
我在本地的测试 redis 环境中随便刷了几条命令,然后打开 appendonly.aof 文件查看,发现里面的内容像下面这样子。
RESP 协议
Redis客户端与服务端通信,使用 RESP 协议通信,该协议是专门为 Redis 设计的通信协议,但也可以用于其它客户端-服务器通信的场景。
RESP 协议有如下几个特点:
-
实现简单;
-
快速解析;
-
可阅读;
客户端发送命令给服务端,服务端拿到命令后进行解析,然后执行对应的逻辑,之后返回给客户端,当然了,这一发一回复都是用的 RESP 协议特点的格式。
一般情况下我们会使用 redis-cli
或者一些客户端工具连接 Redis 服务端。
./redis-cli
然后整个交互过程的命令发送和返回结果像下面这样,绿色部分为发送的命令,红色部分为返回的结果。
这就是我们再熟悉不过的部分了。但是,这并不能看出 RESP 协议的真实面貌。
用 telnet 试试
RESP 是基于 TCP 协议实现的,所以除了用各种客户端工具以及 Redis 提供的 redis-cli
工具,还可以用 telnet 查看,用 telnet 就可以看出 RESP 返回的原始数据格式了。
我本地的 Redis 是用的默认 6379 端口,并且没有设置 requirepass ,我们来试一下用 telnet 连接。
telnet 127.0.0.1 6379
总结
一般像这样的大企业都有好几轮面试,所以自己一定要花点时间去收集整理一下公司的背景,公司的企业文化,俗话说「知己知彼百战不殆」,不要盲目的去面试,还有很多人关心怎么去跟HR谈薪资。
这边给大家一个建议,如果你的理想薪资是30K,你完全可以跟HR谈33~35K,而不是一下子就把自己的底牌暴露了出来,不过肯定不能说的这么直接,比如原来你的公司是25K,你可以跟HR讲原来的薪资是多少,你们这边能给到我的是多少?你说我这边希望可以有一个20%涨薪。
最后再说几句关于招聘平台的,总之,简历投递给公司之前,请确认下这家公司到底咋样,先去百度了解下,别被坑了,每个平台都有一些居心不良的广告党等着你上钩,千万别上当!!!
提供【免费】的Java架构学习资料,学习技术内容包含有:Spring,Dubbo,MyBatis, RPC, 源码分析,高并发、高性能、分布式,性能优化,微服务 高级架构开发等等。
还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书。
发、高性能、分布式,性能优化,微服务 高级架构开发等等。
还有Java核心知识点+全套架构师学习资料和视频+一线大厂面试宝典+面试简历模板可以领取+阿里美团网易腾讯小米爱奇艺快手哔哩哔哩面试题+Spring源码合集+Java架构实战电子书。