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

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左右，保证单实例的响应速度；也保证了数据的安全性，在主从同步时，也不会因为数据量大，而长时间阻塞主机主线程。