第4章 Redis核心数据结构与优化：字符串、哈希、列表、集合、有序集合的应用与性能调优
Redis的五种核心数据结构是面试中的高频考点，面试官通常会围绕选型依据、底层实现、内存优化、批量操作等维度深入提问。掌握每种结构的优缺点和适用场景，并能结合量化指标（如内存占用、时间复杂度、网络开销）进行调优，是拿到高薪Offer的关键。
| 数据结构 | 底层编码 | 典型应用 | 时间复杂度 | 优化要点 |
|---|---|---|---|---|
| String | SDS | 缓存、计数器、分布式锁 | O(1) | 避免大key，使用批量mget |
| Hash | ziplist / hashtable | 对象缓存、购物车 | O(1) 平均 | 控制field数量，合理使用hgetall |
| List | quicklist | 消息队列、时间线 | O(1) 头尾操作 | 避免长list，使用ltrim限制长度 |
| Set | intset / hashtable | 去重、标签系统 | O(1) 添加/删除 | 大数据量慎用sdiff/sinter |
| Sorted Set | ziplist / skiplist | 排行榜、延时队列 | O(log n) | 控制score精度，使用zremrangebyrank |
🎯 面试问题：请对比 Redis 的 String 和 Hash 数据结构，说明在缓存对象时如何选择？
- 面试官考察点
- 1) 对底层编码（SDS vs ziplist/hashtable）的理解；2) 内存占用与网络开销意识；3) 批量操作的灵活性。
- 回答框架
-
- 明确场景：缓存整个对象 vs 频繁修改部分字段。
- String：适用于只读或整体替换，内存紧凑但浪费序列化带宽。
- Hash：适用于部分更新，支持独立字段操作，减少网络开销。
- 量化对比：单 key 小于 2KB 时 String 更优，字段多且更新分散时 Hash 更优。
- 给出结论：根据读写模式选择，并给出配置建议（hash-max-ziplist-entries）。
- 简短示例回答
- “缓存用户信息时，若只需整体获取（如展示页），用 String + JSON 节省 CPU；若需频繁修改积分、等级等独立字段，用 Hash 避免全量序列化。一般字段数＜512 时 Hash 内存效率高，超限后转 hashtable 需预警。” (98字)
- 可能追问
- 1) 如何监控 Hash 是否从 ziplist 转为 hashtable？2) 大字段 Hash 的 hgetall 性能问题如何优化？3) String 序列化用 JSON 还是 protobuf 哪种更快？
- 避坑提醒
- ❌ 不要迷信“Hash 一定比 String 省内存” —— 字段少且值很小时，String 的 jemalloc 分配更紧凑。✅ 实际压测对比内存占比再决定。
🎯 面试问题：如何用 Redis List 实现一个延迟不超过 10ms 的简单消息队列？
- 面试官考察点
- 1) List 的阻塞操作 (BLPOP/BRPOP) 原理；2) 生产者-消费者模型设计；3) 消息可靠性保证（ack 机制）。
- 回答框架
-
- 1. 生产者：用 LPUSH 写入消息到 key。
- 2. 消费者：使用 BRPOP key timeout 阻塞获取，设置超时实现心跳。
- 3. 可靠性：消费后处理业务，若失败则 RPUSH 到备份 list 或重试队列。
- 4. 性能调优：控制 list 长度（定期 ltrim），避免内存堆积。
- 5. 延迟保障：使用连接池、禁用 AOF 每写刷盘、部署同机房。
- 简短示例回答
- “使用 LPUSH 生产消息，消费者 BRPOP 阻塞获取实现 push-pull。为保可靠性，消费后写入另一个‘待确认’list，业务成功后用 LREM 删除。通过 ltrim 限制队列长度 < 20000，避免阻塞时间太长。单机 QPS 可达 5w+，延迟 < 5ms。” (98字)
- 可能追问
- 1) 如何实现可重复消费？2) 多个消费者时是否需要 leader 选举？3) 如果消费者崩溃，消息如何恢复？
- 避坑提醒
- ❌ 不要长时间阻塞在 BRPOP 上导致连接被回收，建议设置合理的 timeout（如 30s）并结合定时重连。✅ 生产环境推荐使用 Stream 替代 List 以获得原生 ACK。
🎯 面试问题：Sorted Set 的底层实现是 ziplist + skiplist，什么条件下会触发转换？如何避免转换带来的性能抖动？
- 面试官考察点
- 1) 对配置参数 (zset-max-ziplist-entries / zset-max-ziplist-value) 的掌握；2) 对 skiplist 时间复杂度的理解；3) 内存与性能的权衡能力。
- 回答框架
-
- 转换条件：元素个数 > zset-max-ziplist-entries (默认128) 或任一个元素长度 > zset-max-ziplist-value (默认64)。
- 转换后：读写复杂度从 O(n) 升至 O(log n)，但内存增加 2~3 倍。
- 避免抖动：根据业务预估最大规模，预分配 skiplist（设置合理配置）或控制元素大小。
- 监控：定期 INFO key 检查编码类型，报警触发转换。
- 简短示例回答
- “当 member 数超 128 或 value 超 64 字节时，ziplist 转 skiplist。建议提前评估：若排行榜固定 200 成员，直接设 zset-max-ziplist-entries=200 强制 skiplist，避免在线转换。转换时 CPU 飙升，可在低峰期手动 zadd 预热。” (99字)
- 可能追问
- 1) 转换后内存暴涨如何处理？2) 如何对 Sorted Set 进行分片优化？3) skiplist 的随机层高如何影响性能？
- 避坑提醒
- ❌ 不要以为 ziplist 一定省内存 —— 当元素大小不统一时，ziplist 的级联更新可能导致插入性能陡降。✅ 用 benchmark 对比两种编码下的吞吐量。
💡 面试加分点：能在回答中主动提及
MEMORY USAGE key 命令、DEBUG OBJECT key 查看编码类型、以及 redis-cli --bigkeys 扫描大 key 的工具，展示出工程化调优能力。