Redis 期中测试

Redis 期中测试，主要面向专栏的基础篇（10 讲）和实践篇的前 10 讲。极客时间《Redis 核心技术与实战》专栏学习笔记 17，部分已经作为留言发布，但是留言太多，排在后面的一般很难被大家看到，所以集中发布在这里，欢迎讨论。

题图来自极客时间《Redis 核心技术与实战》专栏

期中测试题 | 一套习题，测出你的掌握程度

以前是比较厌恶考试的，现在则比较喜欢，因为是给自己看的。

选择题

第一次做 65 分，第二次 80 分，第三次 95。

做了三次都错的一道选择题：

4. Redis 使用 RDB 机制创建快照，关于 RDB 机制，下面的描述哪个是错误的？

A. 使用 save 命令生成 RDB 快照时，是在主线程中执行的，会阻塞主线程

B. RDB 文件是 Redis 实例的镜像，用 RDB 文件恢复实例时，直接把 RDB 文件加载到内存，就可以快速恢复了

C. 和 AOF 文件相比，RDB 文件更小一点

D. 使用 bgsave 命令创建 RDB 快照时，主线程只能处理读请求，写请求操作会被阻塞

答案在文末

问答题

第一题

Redis 在接收多个网络客户端发送的请求操作时，如果有一个客户端和 Redis 的网络连接断开了，Redis 会一直等待该客户端恢复连接吗？为什么？

我认为 Redis 不会一直等待客户端，Redis 在网络连接这里，使用的应该是多路复用，如果客户端不发送连接，Redis 应该是不会等的。如果是发送了一般请求，然后连接断开，那么应该是有一个参数可以指定等待时间。

标准答案要点：

Redis 不会等待客户端恢复连接。Redis 的网络连接由操作系统负责处理……采用 IO 多路复用机制 epoll

第二题

Redis 的主从集群可以提升数据可靠性，主节点在和从节点进行数据同步时，会使用两个缓冲区：复制缓冲区和复制积压缓冲区，这两个缓冲区的作用各是什么？会对 Redis 主从同步产生什么影响吗？

复制缓冲区是用于复制 RDB 文件，复制积压缓冲区是用于保存在同步 RDB 文件时，Redis 服务器上新的请求。

复制缓冲区的大小可能会影响到同步的快慢；复制积压缓冲区的大小可能会影响到在主从同步的时候，是否能够把新的修改请求同步到从库。

标准答案：我搞错了复制缓冲区和复制积压缓冲区的概念。

复制缓冲区 是主从同步时，主节点为从节点创建的输出缓冲区，暂存主节点发送 RDB 文件时收到的写命令操作。RDB 文件传输完成并且在从节点加载完成后，主节点将复制缓冲区中的写命令发给从节点。

如果复制缓冲区溢出，那么主库关闭和从库的网络连接，重新开始全量同步。可以调整 client-output-buffer-limit slave 配置项，增加复制缓冲区大小。

复制积压缓冲区 是在主从节点常规同步时，写命令暂存在复制积压缓冲区中，如果主从网络断连，那么从节点再次连接后，可以从复制积压缓冲区同步尚未复制的命令。

复制积压缓冲区是环形的，如果主从网络断连时间太长，复制积压缓冲区可能被新写入命令覆盖，无法增量复制，只能全量复制。可以调整 repl_backlog_size 的设置，修改复制积压缓冲区大小

第三题

假设在业务场景中，我们有 20GB 的短视频属性信息（包括短视频 ID、短视频基本信息，例如短视频作者、创建时间等）要持久化保存，并且线上负载以读为主，需要能快速查询到这些短视频信息。

现在，我们想使用 Redis 来实现这个需求，请你来设计一个解决方案。我来提几个问题，你可以思考下。

首先，你会用 Redis 的什么数据类型来保存数据？如果我们只用单个实例来运行的话，你会采用什么样的持久化方案来保证数据的可靠性？

其次，如果不使用单实例运行，我们有两个备选方案：一个是用两台 32GB 内存的云主机来运行主从两个 Redis 实例；另一个是用 10 台 8GB 的云主机来运行 Redis Cluster，每两台云主机分别运行一个 Redis 实例主库和从库，分别保存 4GB 数据，你会用哪种方案呢？请聊一聊你的想法。

我会使用 Redis 的 Hash 数据类型来保存数据，短视频 ID 作为 key，其他的属性信息按照 key-value 的形式保存。如果是单个实例的话，那么采用 RDB + AOF 的方式持久化，就是周期性 RDB。

如果不是单实例，那么使用 10 台 8GB 云主机，这样的话可以避免因为实例过大引起的同步问题。10 台云主机，5 套主从库，在可靠性上也有一定的保障。

标准答案要点：

可以使用 AOF 日志来做持久化方案，主要是因为负载以读为主，写命令不会太多，AOF 日志文件不会太大。

另外在选择方案的时候也要考虑经济成本。

选择题答案：选项 D，bgsave 创建快照时，主线程能同时处理读写请求