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

Oct 2, 2020

期中测试题 | 一套习题，测出你的掌握程度-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

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

2020-10-02 蒋德钧来自北京

《Redis核心技术与实战》

课程介绍



讲述：蒋德钧

时长05:29大小5.03M



你好，我是蒋德钧。
咱们的课程已经更新过半了，我看到很多同学一直在坚持学习，课程每次更新后，都会认真回答课后题，而且还会分享自己的思考和经验。但是，我也发现，最近有不少同学都掉队了，积累了很多节课都没有学习过。
从今天开始，我们就进入期中周了。我知道，很多同学平时确实比较忙，想等到有了大块的时间再来学习。所以，在刚开始设计课程时，我就特意设置了期中周。巧的是，我们的期中周刚好和国庆黄金周重合了。那么，现在，就是你赶上进度的好机会。
在开始做题之前，我想多说几句。
Redis 的知识点比较多，而且一旦涉及到性能优化、可靠性保证等需求时，我们就需要和进程、线程、内存管理、磁盘 IO、网络连接等计算机底层系统知识打交道。如果你不熟悉底层系统的知识，在学习 Redis 时，就需要进一步查资料。但是我们平时都很忙，可能会来不及查资料，过一段时间可能就忘了，再想学习时，就需要重新了解，学习成本比较高。
针对这个问题，我想给你分享一下我自己的学习方法。我会用一个 word 文档或者其他的笔记软件，把涉及到的知识点先记录下来。对于那些我没搞清楚的知识点，我会把它们标记为红色，表明这是一个 to-do 项。等我有空的时候，我就会把这个文档拿出来，挨个儿去查看那些标红的知识点，查找相关的资料，补上知识漏洞。
你可以不要小瞧这个文档，日积月累下来，这就是你的知识宝库。你已经了解的知识点以及还需要进一步学习的知识点，在文档中一目了然。而且，咱们常说“温故而知新”，这个文档就是一个“温故知新”的好材料。
另外，我知道很多同学还有一个疑惑：在学习的时候感觉自己都明白了，但是，真正应用的时候，发现自己又说不清楚或者是想不明白。其实，一个潜在的原因就是，我们对技术点的掌握还不牢固，没有形成自己内在的一套知识体系。
所以，我再给你推荐一个非常有用的学习方法，那就是“转述”。每学完一节课之后，就找一个小伙伴，把你学到的内容讲给他 / 她听。如果对方能听明白，就表示你理解了这些内容。我们自己在讲述内容的时候，潜意识会自动梳理知识点以及它们之间的逻辑关系。当然，你也可以写成一篇文章，如果你发现自己讲不清楚，或者是写不出来，那就代表，你对这些内容的理解有偏差，或者是没有把它们纳入你自己的知识体系。这个时候，你一定要找出来知识盲区，及时在留言区提出来，和我或者是其他小伙伴一起交流讨论。
好了，那话不多说，接下来就准备来自测一下吧。我给你出了一套测试题，包括一套选择题和一套问答题。
选择题：满分共 100 分，包含 15 道单选题和 5 道多选题。提交试卷之后，系统自动评分。
问答题：包括 3 道题目，不计入分数，但我希望你能认真回答这些问题，可以把你的答案写在留言区。在 10 月 7 日这一天，我会公布答案。
选择题
问答题第一题Redis 在接收多个网络客户端发送的请求操作时，如果有一个客户端和 Redis 的网络连接断开了，Redis 会一直等待该客户端恢复连接吗？为什么？
第二题Redis 的主从集群可以提升数据可靠性，主节点在和从节点进行数据同步时，会使用两个缓冲区：复制缓冲区和复制积压缓冲区，这两个缓冲区的作用各是什么？会对 Redis 主从同步产生什么影响吗？
第三题假设在业务场景中，我们有 20GB 的短视频属性信息（包括短视频 ID、短视频基本信息，例如短视频作者、创建时间等）要持久化保存，并且线上负载以读为主，需要能快速查询到这些短视频信息。
现在，我们想使用 Redis 来实现这个需求，请你来设计一个解决方案。我来提几个问题，你可以思考下。
首先，你会用 Redis 的什么数据类型来保存数据？如果我们只用单个实例来运行的话，你会采用什么样的持久化方案来保证数据的可靠性？
其次，如果不使用单实例运行，我们有两个备选方案：一个是用两台 32GB 内存的云主机来运行主从两个 Redis 实例；另一个是用 10 台 8GB 的云主机来运行 Redis Cluster，每两台云主机分别运行一个 Redis 实例主库和从库，分别保存 4GB 数据，你会用哪种方案呢？请聊一聊你的想法。
好了，这节课就到这里。希望你能抓住期中周的机会，查漏补缺，快速地提升 Redis 实战能力。我们 10 月 7 日见！

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 34

提建议

38 | 通信开销：限制Redis Cluster规模的关键因素

期中测试题答案 | 这些问题，你都答对了吗？

 写留言

精选留言(10)

sid
2020-10-02
假期是拉开差距的最好时间！！！
21
卫江
2020-10-02
1 对于redis来说，连接的建立是很普遍的操作，如果等待回复，可能造成不必要的内存使用问题。 2 复制缓存区用于保存全量复制期间的变化，如果全量复制太大，又有大量的修改，可能引发缓存溢出，造成主从复制中断，最严重的后果可能造成死循环，从服务器一直启动不了，且对于主的压力也很大。复制积压缓存区用于全量完成之后如果发生断线重连做的优化。为了控制它的大小，使用了环形队列，但是如果修改太频繁，会很快覆盖头部，在主从发生断线之后，就只能从头开始进行全量同步了 3 对于实用的数据结构，不是很清楚查询的需求，如果只是根据id进行查询的话，是可以使用string，不过string对象的空间利用率不是很高，所以也可以使用hash，控制hash的大小，把所有的数据分片到不同的小hash里面，保证内部使用压缩列表来实现，对于持久化方案，最好是rdb+aof，如果是老版本不支持，可以使用aof，因为是以读为主，修改少，自然产生的aof日志就小，最后是选择分片更多，每个主库数据更少肯定更好，就更不用说加上从库来保证更好的可靠性了，理论上来说，主库的内存占有肯定是越小越好的，这样最起码rdb，主从复制，io的压力更小，阻塞我们主线程的元素更少，同时分片更多，并发度也更好，所以不论从那个方面来说，分片越多，每个分片内存越小，都是好的
展开
5
dfuru
2020-10-16
2. 复制缓冲区作用：在主库上对每个从库都维护一个缓冲区，主从在全量复制数据期间，缓存主机接收到写操作命令，等待全量同步完成后，再将复制缓冲区中的数据同步给从库执行。当复制缓冲区溢出后，主库和从库断开连接。复制积压缓冲区，所有从库共享主库上的该环境缓冲区，在增量复制过程中，缓存主从断连期间主库接收到的写命令，当主从网络恢复后，从该缓冲区继续同步命令。若缓冲区满，新写入数据会覆盖旧数据，若旧数据尚未同步，则触发主从全量同步。 3. 使用hash类型保存数据，若单实例保存的可靠性方式：RDB(fork过程影响请求处理性能)+AOF(每秒写回磁盘，使用SSD) 使用Redis Cluster方案，使用2台32G运行主从实例，每台存储20G数据，主库可处理读写请求，从库可分担读请求，从库作为主库的备份提高可靠性。但是，主库存储20G数据，RDB持久化fork耗时长阻塞主线程，从库加收并加载RDB耗时长阻塞从库的读操作。 32G内存偏小，会出现内存紧张，发生Swap，严重影响处理读写请求效率。使用10台8G，每两台构成主从。每个实例存储4G数据，主库可处理读写请求，从库分担读请求且可提高可靠性，每个实例4G，RDB生成对主机性能影响小，RDB传输、从库加载RDB很快完成降低对从库的阻塞，且可防止复制缓冲区溢出问题。
展开
3
William Ning
2022-04-28
答题得分：75 很多都开始遗忘，不清晰了。
2
我不用网名
2020-10-05
题一： Redis不会等待客户端连接。客户端可以选择某种重试策略重连，服务端通过epoll处理相应的网络事件。题二：复制缓冲区与特定客户端或从节点关联，用于服务端传输数据到客户端或从节点。积压缓冲区属于所有从节点，环装结构，Redis服务向里写数据，从节点读。从节点读跟不上写节奏，会导致全量同步。可增大缓冲区，降低全量同步概率。至于影响？前面关于缓冲惨案那一节，听着听着睡着了，抽空补起来。题三：一类关联信息的存储，典型的对象信息，我肯定不假思索的选择hash类型存储。 key按视频id分段(比如： 1-5000,5000-10000)避免bigkey。暂时想不到有没有必要按前面课程"String为什么不香了？"设置参数，保证hash使用压缩列表？单实例的持久化机制。最开始做一次rdb，之后只使用aof，每秒刷盘。主要面向读服务， aof写和重写，阻塞发生的概率会很低，在加上没有数据同步，迁移等压力，这种方式，我觉得可以满足业务要求。关于使用2台32g或10台8g服务器。如果是成长行业务，使用cluster方案肯定会更适合；就题中的场景，个人更倾向2台机器。结构，安装，维护简单，且能满足业务需要！
展开
1
Mr.蜜
2020-10-03
1.redis不会等待客户端重新连接，做客户端断开处理。如果redis等待客户端连接，会影响其他客户端连接的数据处理，从而影响性能。或者说，redis服务器会等待任何客户端的链接，而不单单只等待先前断开的客户端连接，按照epoll模型等待着客户端的连接并做accept和命令处理。 2.复制缓冲区是COW（写时复制）时，对RDB备份和主从数据同步的同时，还有写的操作的缓存。复制积压缓冲区是主从数据同步的环形缓冲区，是一个环形窗口机制，这样在增量同步时，主机可以知道需要同步多少数据给从机。 3.短视频属性信息，一般以K-V键值对数据，所以使用hashmap更合适（使用string+数据序列化，会使得数据的读取需要在客户端做，整存整取，如果发生多客户端写一个数据时，无法保证数据的安全性），这样可以获取单独的数据，也可以使用hgetall获取单个短视频的全量书信信息。在总量20GB的容量需求情况下，使用Redis Cluster更合适，这样保证单个实例在4G左右，保证单实例的响应速度；也保证了数据的安全性，在主从同步时，也不会因为数据量大，而长时间阻塞主机主线程。
展开
1
老大不小
2021-04-28
答：第一题：不会一直等。客户端连接服务端，在服务端会有一个buffer，一直等待的话，占用内存无法释放。一段时间的重连应该还是支持的。第二题：复制缓冲区：客户端，从库和主库之间都有复制缓冲区，单独存在。用来解决网络传输和处理速度不匹配的问题。复制积压缓冲区：所以的从库和主库共用的，对应的有maset_offset和slave_offset，用于主从同步。还可判断主从offset之间的差距，如果比较大，可能会存在主从数据不一致的问题，此时限制客户端访问这台从库。第三题：我会用hashmap来存。单实例下持久化方式，考虑到数据量比较大，单独采用AOF，文件会很大，恢复数据也会很大，所以一定要采用RDB的方式。因为主要是读服务，还可以再使用AOF的方式保存数据。所以我会采用Mix的方式持久化数据。我会选择10台8G的。原因如下：10台实例，肯定是集群，稳定性和扩展性好。并且每台实例上的内存较小（4G），这样在主从同步的时候，以及RDB fork线程的时间都会缩短。如果某台实例挂了，数据访问压力也可以平摊到9台实例上。
展开
escray
2021-04-01
第一题：我认为 Redis 不会一直等待客户端，Redis 在网络连接这里，使用的应该是多路复用，如果客户端不发送连接，Redis 应该是不会等的。如果是发送了一般请求，然后连接断开，那么应该是有一个参数可以指定等待时间。第二题：复制缓冲区是用于复制 RDB 文件，复制积压缓冲区是用于保存在同步 RDB 文件时，Redis 服务器上新的请求。复制缓冲区的大小可能会影响到同步的快慢；复制积压缓冲区的大小可能会影响到在主从同步的时候，是否能够把新的修改请求同步到从库。第三题：我会使用 Redis 的 Hash 数据类型来保存数据，短视频 ID 作为 key，其他的属性信息按照 key-value 的形式保存。如果是单个实例的话，那么采用 RDB + AOF 的方式持久化，就是周期性 RDB。如果不是单实例，那么使用 10 台 8GB 云主机，这样的话可以避免因为实例过大引起的同步问题。10 台云主机，5 套主从库，在可靠性上也有一定的保障。
展开
大饶Raysir
2020-10-22
对于连接，大部分系统的处理方式应该都是超时关闭避免资源浪费吧，redis关闭连接后，客户端只需要重连即可，不影响业务
漫步oo0云端
2020-10-02
1：我认为不会等待恢复连接，断开的连接个人认为会视作处理完成，如果有没处理完的操作，客户端重新请求操作即可。 2：主从复制-复制缓冲区，用于全量复制时临时保存新增数据变更和写入操作。等全量复制完成后，再把复制缓冲区中的数据发送到从库。主从复制-复制积压缓冲区，是一个环形缓冲区，会不断的写入新增数据，当从库和主库断连，锻炼时间内的新增数据会从复制积压缓冲区同步到从库，当新增数据太多发生溢出时会触发全量同步。 3：我觉得就用String保存就可以因为，因为短视频本身就是bigkey，如果放到集和类型中，会导致一个集和变得超级大。然后因为主要是读请求，因此数据实时持久化到磁盘也没问题，因为写操作很少。然后我会厕集群方式，因为高并发访问时，bigkey会导致阻塞主进程，因此多台机器分摊并发压力会提升性能。
展开

