期中测试题-一套习题，测出你的掌握程度
你好，我是蒋德钧。
咱们的课程已经更新过半了，我看到很多同学一直在坚持学习，课程每次更新后，都会认真回答课后题，而且还会分享自己的思考和经验。但是，我也发现，最近有不少同学都掉队了，积累了很多节课都没有学习过。
从今天开始，我们就进入期中周了。我知道，很多同学平时确实比较忙，想等到有了大块的时间再来学习。所以，在刚开始设计课程时，我就特意设置了期中周。巧的是，我们的期中周刚好和国庆黄金周重合了。那么，现在，就是你赶上进度的好机会。
在开始做题之前，我想多说几句。
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 日见！
# 精选评论
点击查看
1 对于redis来说，连接的建立是很普遍的操作，如果等待回复，可能造成不必要的内存使用问题。
2 复制缓存区用于保存全量复制期间的变化，如果全量复制太大，又有大量的修改，可能引发缓存溢出，造成主从复制中断，最严重的后果可能造成死循环，从服务器一直启动不了，且对于主的压力也很大。复制积压缓存区用于全量完成之后如果发生断线重连做的优化。为了控制它的大小，使用了环形队列，但是如果修改太频繁，会很快覆盖头部，在主从发生断线之后，就只能从头开始进行全量同步了
3 对于实用的数据结构，不是很清楚查询的需求，如果只是根据id进行查询的话，是可以使用string，不过string对象的空间利用率不是很高，所以也可以使用hash，控制hash的大小，把所有的数据分片到不同的小hash里面，保证内部使用压缩列表来实现，对于持久化方案，最好是rdb+aof，如果是老版本不支持，可以使用aof，因为是以读为主，修改少，自然产生的aof日志就小，最后是选择分片更多，每个主库数据更少肯定更好，就更不用说加上从库来保证更好的可靠性了，理论上来说，主库的内存占有肯定是越小越好的，这样最起码rdb，主从复制，io的压力更小，阻塞我们主线程的元素更少，同时分片更多，并发度也更好，所以不论从那个方面来说，分片越多，每个分片内存越小，都是好的
2
3
题一： Redis不会等待客户端连接。客户端可以选择某种重试策略重连，服务端通过epoll处理相应的网络事件。
题二：复制缓冲区与特定客户端或从节点关联，用于服务端传输数据到客户端或从节点。积压缓冲区属于所有从节点，环装结构，Redis服务向里写数据，从节点读。 从节点读跟不上写节奏，会导致全量同步。 可增大缓冲区，降低全量同步概率。 至于影响？ 前面关于缓冲惨案那一节，听着听着睡着了，抽空补起来。
题三：一类关联信息的存储，典型的对象信息，我肯定不假思索的选择hash类型存储。 key按视频id分段(比如： 1-5000,5000-10000)避免bigkey。暂时想不到有没有必要按前面课程"String为什么不香了？"设置参数，保证hash使用压缩列表？
单实例的持久化机制。 最开始做一次rdb，之后只使用aof，每秒刷盘。 主要面向读服务， aof写和重写，阻塞发生的概率会很低，在加上没有数据同步，迁移等压力，这种方式，我觉得可以满足业务要求。
关于使用2台32g或10台8g服务器。 如果是成长行业务，使用cluster方案肯定会更适合；就题中的场景，个人更倾向2台机器。结构，安装，维护简单，且能满足业务需要！
2
3
4
5
6
7
1.redis不会等待客户端重新连接，做客户端断开处理。如果redis等待客户端连接，会影响其他客户端连接的数据处理，从而影响性能。或者说，redis服务器会等待任何客户端的链接，而不单单只等待先前断开的客户端连接，按照epoll模型等待着客户端的连接并做accept和命令处理。
2.复制缓冲区是COW（写时复制）时，对RDB备份和主从数据同步的同时，还有写的操作的缓存。复制积压缓冲区是主从数据同步的环形缓冲区，是一个环形窗口机制，这样在增量同步时，主机可以知道需要同步多少数据给从机。
3.短视频属性信息，一般以K-V键值对数据，所以使用hashmap更合适（使用string+数据序列化，会使得数据的读取需要在客户端做，整存整取，如果发生多客户端写一个数据时，无法保证数据的安全性），这样可以获取单独的数据，也可以使用hgetall获取单个短视频的全量书信信息。在总量20GB的容量需求情况下，使用Redis Cluster更合适，这样保证单个实例在4G左右，保证单实例的响应速度；也保证了数据的安全性，在主从同步时，也不会因为数据量大，而长时间阻塞主机主线程。
2
3
假期是拉开差距的最好时间！！！
1：我认为不会等待恢复连接，断开的连接个人认为会视作处理完成，如果有没处理完的操作，客户端重新请求操作即可。
2：主从复制-复制缓冲区，用于全量复制时临时保存新增数据变更和写入操作。等全量复制完成后，再把复制缓冲区中的数据发送到从库。
主从复制-复制积压缓冲区，是一个环形缓冲区，会不断的写入新增数据，当从库和主库断连，锻炼时间内的新增数据会从复制积压缓冲区同步到从库，当新增数据太多发生溢出时会触发全量同步。
3：我觉得就用String保存就可以因为，因为短视频本身就是bigkey，如果放到集和类型中，会导致一个集和变得超级大。
然后因为主要是读请求，因此数据实时持久化到磁盘也没问题，因为写操作很少。
然后我会厕集群方式，因为高并发访问时，bigkey会导致阻塞主进程，因此多台机器分摊并发压力会提升性能。
2
3
4
5
6