外观
系统设计 速查卡
🎯 覆盖 20 题 | ⭐ 高频 4 题 | 预计扫描 10 分钟 📌 系统设计题答题框架：整体架构思路 → 核心问题拆解 → 兜底/降级方案
一、秒杀 / 高并发
知识地图：前端限流→CDN→网关限流→Redis预扣→MQ削峰→DB乐观锁
⭐ 秒杀系统 + 防超卖
一句话： 分层削峰（前端→网关→Redis→MQ→DB），防超卖三道防线——Redis Lua 原子预扣减(主) + MQ 异步下单(削峰) + DB 乐观锁(兜底)。
七层架构链：
① 前端限流(倒计时/答题) → ② CDN(页面静态化) → ③ 网关限流(令牌桶)
→ ④ Redis Lua 预扣库存 → ⑤ MQ 异步下单 → ⑥ 消费者处理 → ⑦ DB 乐观锁兜底Redis Lua 防超卖核心： GET stock → stock<=0 拒绝 → DECR stock（三步原子执行）
DB 兜底： UPDATE product SET stock=stock-1 WHERE id=? AND stock>0
一人一单： Redis SETNX 快速拦截 + DB 唯一索引(user_id, product_id)兜底
⚠️ 易错：Redis 预扣减不直接查 DB，全在内存操作；但需保证 Redis 和 DB 库存最终一致（定期对账+异常补偿）
二、缓存设计
知识地图：L1 本地缓存(Caffeine) → L2 Redis → L3 数据库
缓存更新策略（Cache Aside）
写操作： 先更新 DB → 再删除 Cache（不是更新）
多级缓存一致性： 短 TTL(5s) + Redis Pub/Sub 广播失效
AI 结果缓存： 对 query 归一化(trim+lowercase) → SHA256 生成 key → Redis 存结果带 TTL；Semantic Cache 用向量相似度匹配近似问题
三、排行榜 / 推送
⭐ Redis ZSet 实时排行榜
一句话： 用 ZSet 存排行数据（score=分数, member=用户ID），ZADD/ZINCRBY 原子更新，ZREVRANGE 取 TOP N，天然有序。
ZADD leaderboard 1500 user:1001 # 写入/更新
ZINCRBY leaderboard 50 user:1001 # 原子加分
ZREVRANGE leaderboard 0 9 WITHSCORES # 取 Top10
ZREVRANK leaderboard user:1001 # 查排名分周期： key 中嵌入时间维度（leaderboard:daily:2024-01-15）+ 设置 EXPIRE
超大量用户： 只保留 Top 10000（ZREMRANGEBYRANK 清理尾部），底部用户显示"10000+"
Feed 流（朋友圈）
推拉结合： 普通用户 = 推模式(发帖时推到关注者列表)；大 V = 拉模式(读时实时拉取合并)
原因： 大 V 用推模式 = 百万粉丝 × 百万次 Redis 写，写放大严重
四、订单超时
⭐ 订单 15 分钟超时取消
一句话： 推荐 RocketMQ 延迟消息（主）+ 本地消息表（兜底补偿），消费时幂等检查订单状态。
| 方案 | 优点 | 缺点 |
|---|---|---|
| MQ 延迟消息(推荐) | 可靠，失败可重试 | RocketMQ 延迟级别固定 |
| Redis ZSet | 精确到秒，支持任意延迟 | Redis 宕机可能丢失 |
| 定时扫库 | 简单 | 全表扫描性能差，不精确 |
| 时间轮(Netty) | 纯内存高效 | 进程重启丢失 |
生产级方案：
下单 → DB 插订单+本地消息表(同事务) → 发 MQ 延迟消息
15min 后消费 → 幂等检查(状态仍是PENDING?) → 取消订单 → 更新消息表
定时任务兜底(每5min) → 扫描本地消息表中超时未处理记录 → 补发或直接取消五、限流 / 熔断
限流三层
接入层(Nginx): 全局 QPS 限制
网关层(Gateway): 按接口/用户限流
应用层(Sentinel): 方法级细粒度熔断状态机
Closed(正常) → 错误率>阈值 → Open(快速失败) → 等待恢复 → Half-Open(少量测试)
→ 测试成功回 Closed / 失败重回 Open降级策略（从好到坏）： 返回缓存旧数据 > 返回默认值 > 降级提示 > 快速失败 503
六、分布式 / 大数据
跨实例限流
Redis 分布式限流： 所有实例共享 Redis 计数器(Lua 原子操作) 或 Redisson RRateLimiter
链路追踪
OpenTelemetry： Trace ID(全局) + Span ID(子操作)，通过 HTTP Header 传播
一致性方案： Saga(补偿式,适合长流程) / TCC(预留式,资金类) / 本地消息表(最终一致)
大数据 Top K
10GB 日志找 Top10 接口： Hash 分片为 100 个小文件(各100MB) → 各片 HashMap 统计 + 小顶堆 Top10 → 汇总 100 个 Top10 取全局 Top10
两个 20GB 文件找重复 URL： Hash 分片到 1000 个桶(相同 URL 必在同一桶) → 逐桶 HashSet 求交集
七、AIGC
LLM 响应慢的优化
最核心： 流式输出(SSE)——每生成一个 token 立即推送，首字节 200ms 内可见
① 流式输出(SSE) → ② 缓存(Semantic Cache) → ③ 预加载(输入时预测提前请求)
→ ④ 分段返回(先摘要后详情) → ⑤ 小模型路由(简单问题用快模型)
→ ⑥ TTFT 优化(KV Cache预热/投机采样/量化部署)补充速览
| 关键词 | 核心答案 |
|---|---|
| 转账服务 | 幂等(transferId去重) + 分库分表 + 同库事务(FOR UPDATE固定顺序防死锁) + 跨库TCC |
| 退单处理 | DB 库存+1 → Redis 库存+1 → 删一人一单标记；用退款单ID做幂等防重 |
| 秒杀 QPS 隔离 | 物理隔离(独立集群) / 逻辑隔离(线程池隔离) / Sentinel 热点参数限流 |
| 工单超时定时器 | 小顶堆(堆顶=最近超时)；Redis 用 ZSet(score=超时时间戳)；DB 用 execute_at 索引 |
| 新闻推荐 | 召回(规则+协同过滤+向量) → 过滤(已读+黑名单) → 排序(点击率+完读率+时效性) |
| 兴趣动态变化 | 时间衰减 + 短期/长期兴趣分离 + 会话上下文 + 显式偏好 |
| ⭐ 短链系统 | 分布式ID+Base62生成短码；Redis缓存热点(命中率>95%)；302重定向；防刷+过期清理+统计分析 |
| 分布式任务调度 | 调度中心+执行器架构；抢占式/中心分配/一致性哈希；Redis分布式锁防重复执行；失败重试+告警 |
🧠 助记汇总
| 口诀 | 含义 |
|---|---|
| 前CDN关Redis MQ DB | 秒杀七层架构 |
| Redis预扣→MQ削峰→DB兜底 | 防超卖三道防线 |
| 关开半 | 熔断状态机：Closed→Open→Half-Open |
| 缓默降快 | 降级四级：缓存旧数据/默认值/降级提示/快速失败 |
| 分片→各片TopK→汇总 | 大数据 TopK 通用模式 |
| ID+Base62→Redis→302 | 短链系统核心链路 |
✅ 自测清单
| # | 问题 | 你能说出... |
|---|---|---|
| 1 | 秒杀系统 | 七层架构 + 防超卖三道防线 |
| 2 | 一人一单 | Redis SETNX + DB 唯一索引 + 退单处理 |
| 3 | 排行榜 | ZSet 命令 + 分周期 + 大数据量处理 |
| 4 | 订单超时 | 四种方案对比 + 生产级方案 |
| 5 | 限流熔断 | 三层限流 + 熔断状态机 + 降级策略 |
| 6 | Feed 流 | 推拉结合 + 为什么大 V 用拉 |
| 7 | 大数据 TopK | Hash 分片 + 小顶堆合并 |
| 8 | AIGC 响应优化 | 六大手段（SSE 最核心） |
| 9 | 短链系统 | ID+Base62 + Redis缓存 + 302 重定向 |
| 10 | 分布式任务调度 | 调度中心+执行器 + 防重复执行 |
💡 首次全部过一遍 → 第2天只过答不上来的 → 第4天再复习 → 面试前一天最后扫一遍