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

假期是拉开差距的最好时间！！！

1 对于redis来说，连接的建立是很普遍的操作，如果等待回复，可能造成不必要的内存使用问题。 2 复制缓存区用于保存全量复制期间的变化，如果全量复制太大，又有大量的修改，可能引发缓存溢出，造成主从复制中断，最严重的后果可能造成死循环，从服务器一直启动不了，且对于主的压力也很大。复制积压缓存区用于全量完成之后如果发生断线重连做的优化。为了控制它的大小，使用了环形队列，但是如果修改太频繁，会很快覆盖头部，在主从发生断线之后，就只能从头开始进行全量同步了 3 对于实用的数据结构，不是很清楚查询的需求，如果只是根据id进行查询的话，是可以使用string，不过string对象的空间利用率不是很高，所以也可以使用hash，控制hash的大小，把所有的数据分片到不同的小hash里面，保证内部使用压缩列表来实现，对于持久化方案，最好是rdb+aof，如果是老版本不支持，可以使用aof，因为是以读为主，修改少，自然产生的aof日志就小，最后是选择分片更多，每个主库数据更少肯定更好，就更不用说加上从库来保证更好的可靠性了，理论上来说，主库的内存占有肯定是越小越好的，这样最起码rdb，主从复制，io的压力更小，阻塞我们主线程的元素更少，同时分片更多，并发度也更好，所以不论从那个方面来说，分片越多，每个分片内存越小，都是好的

答题得分：75 很多都开始遗忘，不清晰了。

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很快完成降低对从库的阻塞，且可防止复制缓冲区溢出问题。

题一： Redis不会等待客户端连接。客户端可以选择某种重试策略重连，服务端通过epoll处理相应的网络事件。 题二：复制缓冲区与特定客户端或从节点关联，用于服务端传输数据到客户端或从节点。积压缓冲区属于所有从节点，环装结构，Redis服务向里写数据，从节点读。 从节点读跟不上写节奏，会导致全量同步。 可增大缓冲区，降低全量同步概率。 至于影响？ 前面关于缓冲惨案那一节，听着听着睡着了，抽空补起来。 题三：一类关联信息的存储，典型的对象信息，我肯定不假思索的选择hash类型存储。 key按视频id分段(比如： 1-5000,5000-10000)避免bigkey。暂时想不到有没有必要按前面课程"String为什么不香了？"设置参数，保证hash使用压缩列表？ 单实例的持久化机制。 最开始做一次rdb，之后只使用aof，每秒刷盘。 主要面向读服务， aof写和重写，阻塞发生的概率会很低，在加上没有数据同步，迁移等压力，这种方式，我觉得可以满足业务要求。 关于使用2台32g或10台8g服务器。 如果是成长行业务，使用cluster方案肯定会更适合；就题中的场景，个人更倾向2台机器。结构，安装，维护简单，且能满足业务需要！

1.redis不会等待客户端重新连接，做客户端断开处理。如果redis等待客户端连接，会影响其他客户端连接的数据处理，从而影响性能。或者说，redis服务器会等待任何客户端的链接，而不单单只等待先前断开的客户端连接，按照epoll模型等待着客户端的连接并做accept和命令处理。 2.复制缓冲区是COW（写时复制）时，对RDB备份和主从数据同步的同时，还有写的操作的缓存。复制积压缓冲区是主从数据同步的环形缓冲区，是一个环形窗口机制，这样在增量同步时，主机可以知道需要同步多少数据给从机。 3.短视频属性信息，一般以K-V键值对数据，所以使用hashmap更合适（使用string+数据序列化，会使得数据的读取需要在客户端做，整存整取，如果发生多客户端写一个数据时，无法保证数据的安全性），这样可以获取单独的数据，也可以使用hgetall获取单个短视频的全量书信信息。在总量20GB的容量需求情况下，使用Redis Cluster更合适，这样保证单个实例在4G左右，保证单实例的响应速度；也保证了数据的安全性，在主从同步时，也不会因为数据量大，而长时间阻塞主机主线程。

95, hhh。上完课，对 redis的理解深了不少。

60，及格万岁

答： 第一题： 不会一直等。客户端连接服务端，在服务端会有一个buffer，一直等待的话，占用内存无法释放。一段时间的重连应该还是支持的。 第二题： 复制缓冲区：客户端，从库和主库之间都有复制缓冲区，单独存在。用来解决网络传输和处理速度不匹配的问题。 复制积压缓冲区：所以的从库和主库共用的，对应的有maset_offset和slave_offset，用于主从同步。还可判断主从offset之间的差距，如果比较大，可能会存在主从数据不一致的问题，此时限制客户端访问这台从库。 第三题： 我会用hashmap来存。单实例下持久化方式，考虑到数据量比较大，单独采用AOF，文件会很大，恢复数据也会很大，所以一定要采用RDB的方式。因为主要是读服务，还可以再使用AOF的方式保存数据。所以我会采用Mix的方式持久化数据。 我会选择10台8G的。原因如下：10台实例，肯定是集群，稳定性和扩展性好。并且每台实例上的内存较小（4G），这样在主从同步的时候，以及RDB fork线程的时间都会缩短。如果某台实例挂了，数据访问压力也可以平摊到9台实例上。

第一题：我认为 Redis 不会一直等待客户端，Redis 在网络连接这里，使用的应该是多路复用，如果客户端不发送连接，Redis 应该是不会等的。如果是发送了一般请求，然后连接断开，那么应该是有一个参数可以指定等待时间。 第二题：复制缓冲区是用于复制 RDB 文件，复制积压缓冲区是用于保存在同步 RDB 文件时，Redis 服务器上新的请求。 复制缓冲区的大小可能会影响到同步的快慢；复制积压缓冲区的大小可能会影响到在主从同步的时候，是否能够把新的修改请求同步到从库。 第三题：我会使用 Redis 的 Hash 数据类型来保存数据，短视频 ID 作为 key，其他的属性信息按照 key-value 的形式保存。如果是单个实例的话，那么采用 RDB + AOF 的方式持久化，就是周期性 RDB。 如果不是单实例，那么使用 10 台 8GB 云主机，这样的话可以避免因为实例过大引起的同步问题。10 台云主机，5 套主从库，在可靠性上也有一定的保障。