🏗️ 系统设计与场景题

🎯 系统设计题怎么答？（答题框架）

系统设计题没有标准答案，面试官看的是你有没有框架、会不会权衡。千万不要一上来就讲细节。

• 第一步：问清楚需求——功能边界是什么？QPS/DAU 量级？读多还是写多？能接受最终一致吗？主动问需求本身就是加分项
• 第二步：给量级估算——日活 × 人均请求 = 日均 QPS，峰值按 3~5 倍算；单机 MySQL 大约扛几千 QPS、Redis 单机约 10 万 QPS。用数量级说明「为什么要加缓存/分片」
• 第三步：画整体架构——接入层（DNS/CDN/网关）→ 应用层（无状态、可水平扩）→ 缓存层 → 存储层（分库分表/读写分离）→ 异步层（MQ）
• 第四步：逐个解决难点——通常是这几个：高并发读（缓存）、高并发写（异步削峰 + 分片）、数据一致性、幂等、超时与降级
• 第五步：说清权衡——每个方案都要说「代价是什么」。只讲优点不讲代价，是初级和高级的分水岭

⚡ 场景一：秒杀系统怎么设计？

核心矛盾：瞬时几十万请求抢几百件库存。目标不是「让所有人买到」，而是别把系统打垮 + 不超卖。

• ① 前端限流——按钮置灰、答题防脚本、同一用户 N 秒只能提交一次
• ② 网关/CDN 层拦截——静态资源走 CDN；网关做限流（令牌桶），把绝大部分无效流量挡在应用外
• ③ 库存预热到 Redis——活动开始前把库存写入 Redis，用 DECR 或 Lua 脚本原子扣减，扣到负数直接返回「已售罄」。这一步挡住了 99% 的流量，DB 完全无感
• ④ 异步下单——Redis 扣减成功的请求发到 MQ，由消费者慢慢写订单、扣 DB 库存，实现削峰
• ⑤ 数据库兜底——UPDATE stock SET count = count - 1 WHERE id = ? AND count > 0，影响行数为 0 说明卖完了。绝不能先 SELECT 再 UPDATE
• ⑥ 幂等——同一用户重复提交要用唯一索引或 Redis SETNX 拦住

-- 返回 1 表示扣减成功，0 表示库存不足，-1 表示重复下单
local stock = redis.call('GET', KEYS[1])
if not stock then return -1 -- 库存没预热
if tonumber(stock) <= 0 then return 0 end
-- 用 setnx 记录该用户已下单，防止重复
if redis.call('SETNX', KEYS[2], 1) == 0 then return -1 end
redis.call('DECR', KEYS[1])
return 1

🔗 场景二：短链系统怎么设计？

• 核心需求——长链接 → 短链接（如 t.cn/abc123），访问短链 302 跳转回长链。读远多于写（100:1 以上）
• 短码怎么生成？三种方案：

• 存储设计——MySQL 存映射（短码做唯一索引）；热点映射放 Redis（读多写少，缓存命中率极高）
• 跳转用 301 还是 302？——302。301 是永久重定向，浏览器会缓存，之后就绕过你的服务器了——那样就统计不到点击量、也改不了目标地址
• 怎么防遍历？——短码加随机位、限流、对不存在的短码直接返回 404 不打 DB

🏆 场景三：实时排行榜怎么做？

• 核心方案：Redis ZSet——ZADD 更新分数、ZREVRANGE 取 TopN、ZREVRANK 查我的排名。底层是跳表 + 哈希表，增删改查都是 O(log n)

# 增加分数（用户 1001 加 10 分）
ZINCRBY rank:daily 10 user:1001

# 取今日 Top 10（带分数）
ZREVRANGE rank:daily 0 9 WITHSCORES

# 查某人的排名（从 0 开始，所以要 +1）
ZREVRANK rank:daily user:1001

# 取分数区间的人数（如 100 分以上有多少人）
ZCOUNT rank:daily 100 +inf

• 数据量很大的问题——百万级 ZSet 内存占用高、排序变慢。方案：分层榜单（只保留 Top 1000 在 Redis，其余落库）+ 分片 ZSet（按用户 ID 哈希分片，再合并各片 TopN）
• 日榜/周榜/月榜怎么做？——多个 ZSet + 定时任务归并（ZUNIONSTORE）；过期榜单直接设 TTL 自动清理
• 分数相同时的排序？——ZSet 按 score 排序，score 相同则按 member 字典序。若要求「先达到者靠前」，可以把时间戳编码进 score 的低位（如 score * 10^10 - timestamp）
• 怎么防刷分？——业务层校验 + 频率限制 + 异步对账；关键榜单定期从 DB 重算校准

⏰ 场景四：订单超时未支付自动关闭怎么做？

这是延迟任务的经典题，四种方案各有取舍：

• 生产推荐——RocketMQ 延迟消息（可靠）+ 定时任务兜底对账（防漏）。「延迟消息 + 定时补偿」是标准答案
• 为什么不能只用 Redis 过期监听？——Redis 的 key 过期事件是不可靠投递：如果那一刻没有客户端订阅、或者 key 一直没被访问，事件可能丢失。用它处理钱相关业务会出事
• 关单时要注意什么？——必须幂等（用户可能正好在关单瞬间支付了）：UPDATE order SET status='CLOSED' WHERE id=? AND status='UNPAID'，用状态条件保证只关一次

🔢 场景五：分布式 ID 怎么生成？

0 | 0000000000 0000000000 0000000000 0000000000 0 | 00000 | 00000 | 000000000000
符号位(1) |            时间戳(41 bit, 毫秒)            | 机房(5) | 机器(5) | 序列(12)

// 41 位毫秒时间戳 ≈ 69 年
// 每毫秒最多 2^12 = 4096 个 ID → 单机约 409 万 ID/秒
// 趋势递增 → 对 MySQL 聚簇索引友好

• 最大的坑：时钟回拨——服务器 NTP 校时可能让时间倒退，此时生成的 ID 会重复。处理方式：

• workerId 怎么分配？——配置文件写死（简单但易冲突）、Redis INCR 分配、ZooKeeper 顺序节点、或启动时向 DB 注册
• 为什么不用 UUID 做 MySQL 主键？——UUID 无序，插入时 B+ 树要频繁分裂和移动，性能差、页利用率低。业务主键可以用 UUID 保证唯一，但要另设自增/雪花列做聚簇索引

🚦 场景六：限流与降级怎么做？

限流控制请求速率，熔断应对下游故障，降级是主动砍非核心功能。三者常一起出现。

// 每秒放 100 个令牌（令牌桶）
RateLimiter limiter = RateLimiter.create(100.0);

if (limiter.tryAcquire()) {
    // 放行
} else {
    // 限流：返回 429 或走降级逻辑
}

-- KEYS[1]=桶 key  ARGV[1]=速率  ARGV[2]=容量  ARGV[3]=当前毫秒时间戳
local rate, cap, now = tonumber(ARGV[1]), tonumber(ARGV[2]), tonumber(ARGV[3])
local bucket = redis.call('HMGET', KEYS[1], 'tokens', 'ts')
local tokens = tonumber(bucket[1]) or cap
local ts = tonumber(bucket[2]) or now
-- 按流逝时间补充令牌，上限为容量
tokens = math.min(cap, tokens + (now - ts) / 1000 * rate)
local allowed = 0
if tokens >= 1 then tokens = tokens - 1; allowed = 1 end
redis.call('HMSET', KEYS[1], 'tokens', tokens, 'ts', now)
redis.call('PEXPIRE', KEYS[1], math.ceil(cap / rate * 1000))
return allowed

🎤 系统设计通用追问（10 条）

• QPS 怎么估算？——日请求量 ÷ 86400 = 日均 QPS，峰值按 3~5 倍。例：日活 100 万、人均 20 次请求 → 日均约 230 QPS，峰值约 1000 QPS
• 单机能力大概多少？——MySQL 单机约几千 QPS（含索引查询）；Redis 单机约 10 万 QPS；Nginx 单机可到几万。这些是数量级，用来判断要不要加缓存/分片
• 什么时候分库分表？——先试：索引优化 → 冷数据归档 → 缓存扛读。还不行再分（单表千万~亿级、写入瓶颈）。分片是最后手段，成本极高
• 缓存和 DB 怎么保持一致？——Cache Aside（先更新 DB 再删缓存）+ 失败重试 + 延迟双删 / canal 订阅 binlog。强一致就别用缓存
• 怎么保证幂等？——唯一索引（最可靠）、Redis SETNX、状态机、乐观锁。用业务键而不是消息 ID
• 怎么防雪崩？——缓存：TTL 随机化、多级缓存、集群高可用；服务：限流、熔断、降级、隔离（线程池/信号量）
• 怎么排查线上慢？——先看监控定位层次（DB？缓存？下游？），再上工具：top/iostat 看资源、jstack 看线程、慢 SQL 日志看 DB、链路追踪看耗时分布
• 怎么设计一个分布式锁？——Redis SETNX EX + 唯一 value + Lua 校验删除 + 续期（看门狗）+ fencing token；或 ZooKeeper 临时顺序节点
• 大流量下怎么做灰度发布？——按用户 ID 哈希 / 请求头 / 百分比路由，网关层做；新老版本共存，出问题快速回滚
• 如果让我加一个新功能，怎么不改坏老系统？——开关（配置中心动态生效）、旁路（新逻辑异步跑，对账一致后再切主路）、限流保护、可回滚