外观
Redis 数据结构与缓存
- 状态：未准备
- 适用方向：Go 全栈 / Go 后端
- 最近复习：待填写
- 下次复习：待安排
一句话回答
Redis 提供多种内存数据结构；缓存降低重复读取成本，同时引入过期、内存容量和数据库一致性问题，应先定义允许多旧、失效后怎么办。
原理解释
| 类型 | 典型场景 | 要说明的边界 |
|---|---|---|
| String | 对象序列化、计数 | 大 value 与并发更新 |
| Hash | 对象字段 | 字段与整体的生命周期策略 |
| List | 最近消息、简单队列 | 长度裁剪、可靠消费需额外协议 |
| Set | 去重、成员集合 | 大集合操作成本 |
| Sorted Set | 排行、时间排序 | 分数相同的排序与分页 |
| Stream | 消费组日志 | 确认、pending 与重投递 |
cache-aside：先读缓存，未命中读数据库并回填；写入通常先提交数据库再失效缓存。并发旧读仍可能在删除后回填旧值，应按一致性目标配合 TTL、版本、串行化或事件失效，不能声称这一顺序彻底解决所有竞态。
穿透是请求不存在的数据，可用短期空值缓存、输入校验或布隆过滤器；过滤器可能误判存在，仍要查数据。击穿是热点 key 失效，可合并回源、预热或逻辑过期；雪崩是大量失效或缓存整体故障，需抖动 TTL、限流、降级和回源保护。
场景与边界
过期删除与内存淘汰是两件事。核心数据不能只因用了 Redis 就认为不会丢；RDB、AOF 和复制各有恢复窗口。大 key、慢命令和无界 List 会拖累服务，需监测命令耗时、内存和命中率。
项目中的应用
沿 EinoTalk Redis 缓存核对消息 List、在线路由的 TTL 和故障行为。当前材料中的 Pipeline 不能讲成整个缓存更新原子完成。
常见追问
- Redis 是单线程所以没并发问题？ 命令执行模型不能保证客户端多步逻辑原子，网络 IO 等也不是简单一句单线程。
- Pub/Sub 是可靠队列吗？ 不是持久化消息日志，断线期间消息可能丢失。
- 缓存不可用怎么办？ 按容量限流回源或降级，不能把全部流量无条件压给数据库。