系统设计

建议六步法。一明确问题与需求：功能性需求（核心用例三五个）与非功能性需求（QPS、延迟、一致性、可用性、数据量），主动和面试官对齐范围；二估算容量：日活推 QPS 峰值（乘二三倍系数）、存储与带宽、内存与连接数，决定技术选型的量级；三画高层架构：客户端、网关、服务、存储、缓存的粗粒度框图先跑通主流程；四细化数据模型与 API：表结构或键值模型、接口契约；五逐点深挖：按瓶颈（读多写少、热点、一致性、扩展）引入缓存、分库分表、消息队列、CDN 与多副本，说明取舍；六总结与演进：单点、故障模式、监控与降级。关键是边画边说、每步给取舍理由，而不是直接报一个终态架构图。

方法是自上而下连乘加安全系数。例：一亿注册用户，日活百分之二十即两千万，人均每天 20 次请求则日请求四亿；按秒均值约 46 QPS（除以 86400），但流量集中白天约 8 小时且峰谷比 3 到 5 倍，设计峰值取 3 倍均值约 170 QPS，读写比 10 比 1 时写约 17 QPS。存储：每条记录 1KB，日增 4 亿条约 400GB，压缩与冷热分层后按年 TB 级规划。带宽：峰值响应平均 50KB 则出带宽约 8.5 Gbps。内存缓存热点 20% 数据约需百 GB 量级。数字精确与否不重要，重要的是单位换算（毫秒、微秒、KB 到 TB）与数量级正确，并反向校验选型（单机 MySQL 约能扛数千 QPS、Redis 十万级）。

主流程是长链换短码与短码跳长链。短码生成两条路线：哈希（MurmurHash 取 base62 截断加冲突重试或加盐）与发号器（预分配号段或 Redis 自增，再 base62 编码，天然无冲突可预测）。存储用 KV（短码到长链、过期时间、用户），量大数据量级仅 TB 级单表可扛，可分片键取短码。跳转读多写少：布隆或本地缓存热点短码，回源加缓存兜底；301 永久跳转利于浏览器缓存但统计曝光少，302 便于统计点击。工程细节：自定义短链与黑名单、防恶意域、过期清理（惰性删除）、全局唯一约束与幂等（同长链同人返回同码或按需求允许重复）；高可用靠多副本与缓存降级。答出号码发器与哈希两条路线的取舍即可拿高分。

核心思想是层层削峰尽量让少量请求触达数据库。入口层：静态资源 CDN 化，按钮置灰防重复点击，答题或验证码打散瞬时尖峰，网关按用户与 IP 限流。库存层：库存预热进 Redis，用 Lua 脚本原子地校验加扣减（或 DECR 配防超卖判负），扣减成功才进入下单链路；风险用户与机器人过滤。异步下单：扣减成功后发消息队列，订单服务慢慢消费落库、创建支付单，前端轮询或推送结果；超时未支付回滚库存（延迟消息）。数据层：库存最终以数据库为准，用行锁或乐观库存字段防超卖，对账任务兜底。可用性：服务单独分组隔离防拖垮主站、降级预案（队列满直接拒绝并提示）、热点 key 分段（库存拆十份降低单 key 争用）。能讲 Redis 原子扣减加 MQ 异步落库加防超卖三层即完整。

无状态指请求自包含、实例不保存影响后续请求的本地状态（会话、文件、内存锁），任何实例可处理任何请求，扩容缩容与滚动发布无粘性。改造要点：会话外置（见下）、本地缓存换分布式缓存或接受副本不一致、任务调度走队列与分布式锁、文件进对象存储、定时任务收敛到调度器避免多实例重复跑。会话方案对比：粘性会话（负载均衡按 cookie 固定路由）简单但破坏无状态与故障转移；会话复制（容器间同步）小集群可用复杂度陡增；集中存储（Redis 存 session，cookie 只放 id）是主流，配持久化与过期策略；彻底方案是无会话的令牌化（JWT 或 opaque token 加 introspection），网关统一鉴权，服务无感。答题先定义无状态再给会话四方案取舍。