【设计面试】专题精选系统设计各方向的经典面试题，覆盖设计基础、系统设计、功能设计、场景设计、安全设计、设计模式六大板块。题目源自真实面试场景，高星题配备拓展追问与生产场景题，侧重考察架构思维、方案权衡与实战应用能力，适合系统性备战资深岗位设计类面试。

📖 内容

• 设计基础面试 💯
• 系统设计面试 💯
• 功能设计面试 💯
• 场景设计面试 💯
• 安全设计面试 💯
• 设计模式面试 💯

【中等】如何设计一个排行榜功能？⭐⭐⭐

🎯 目标等级：L2 ｜ ⏱ 建议用时：15 min ｜ 🏷 标签：功能设计 / 缓存

💎 关键结论

首选 Redis zset（有序集合）：以用户为 member、排行指标为 score，天然有序。ZINCRBY 原子加分，ZREVRANGE 取 Top N，ZREVRANK 查个人名次，O(logN) 复杂度，实时且简单。

⚡记忆卡片

【中等】如何在 10 亿个数据中找到最大的 1 万个？⭐⭐⭐

🎯 目标等级：L2 ｜ ⏱ 建议用时：12 min ｜ 🏷 标签：场景设计 / 海量数据 TopK

💎 关键结论

维护一个容量为 1 万的最小堆：读入前 1 万条建堆，之后每条数据与堆顶比较，比堆顶大才替换堆顶并下沉调整。遍历一遍 10 亿数据后，堆中即最大的 1 万个。时间复杂度 O(n log K)，堆仅占约 40KB，适合数据无法全量装入内存的场景。

⚡记忆卡片

【中等】如何设计一个接口签名验证机制？⭐⭐⭐

🎯 目标等级：L2 ｜ ⏱ 建议用时：15 min ｜ 🏷 标签：安全设计 / 接口签名

💎 关键结论

接口签名验证靠三件套：签名防篡改、时间戳防过期、随机数防重放。客户端把参数（含时间戳、nonce）按字典序拼接加上约定密钥算哈希签名；服务端同规则重算比对，时间戳超窗口拒绝，nonce 存 Redis 窗口期内只允许一次。两边算法一致即安全。

⚡记忆卡片

• 口诀：参数排序加密钥，哈希签名两边同；时间戳卡窗口期，nonce 入 Redis 只一次
• 关键词：参数排序 ／ HMAC-SHA256 ／ 时间戳窗口 ／ nonce 防重放
• 链路：参数排序拼接 → 加密钥算哈希 → 服务端重算比对 → 时间戳校验 → nonce 查重

【困难】如何设计一个秒杀系统？⭐⭐⭐⭐⭐

🎯 目标等级：L3-L4 ｜ ⏱ 建议用时：20 min ｜ 🏷 标签：系统设计 / 秒杀

💎 关键结论

秒杀应对的是瞬时海量请求，思路是「稳、准、快」：前端静态页 + CDN 挡读流量，答题 + 限流削峰，扣库存用 Redis + Lua 原子操作保证不超卖，只有扣减成功的请求进 MQ 异步建单。最终 DB 写入量等于库存量，而不是请求量。

⚡记忆卡片

• 口诀：静态挡、答题缓、限流削、Lua 扣
• 关键词：瞬时海量请求 ／ 超卖 ／ 分层过滤 ／ Redis+Lua ／ 异步建单
• 链路：前端静态 + CDN → 答题限流 → Redis Lua 扣库存 → MQ 削峰 → 异步建单 → 对账兜底

综述

【简单】什么是设计模式？⭐⭐

🎯 目标等级：L2 ｜ ⏱ 建议用时：5 min ｜ 🏷 标签：设计模式 / 概念

💎 关键结论

设计模式是针对常见软件设计问题的可复用解决方案，是前人总结的最佳实践模板。它不是现成代码，而是一种设计思想，指导如何组织类和对象解决特定场景的问题。

⚡记忆卡片

• 口诀：模式不是代码，是解题思路
• 关键词：可复用 ／ 设计思想 ／ 特定场景 ／ 最佳实践
• 链路：常见问题 → 前人实践 → 提炼为模式 → 指导类与对象的组织方式

架构设计

【中等】一个单体项目整体吞吐达到 1 万 QPS，要微服务化拆分吗？⭐⭐⭐⭐

🎯 目标等级：L2 ｜ ⏱ 建议用时：15 min ｜ 🏷 标签：架构设计 / 微服务拆分

💎 关键结论

不建议拆。1 万 QPS 不是微服务拆分的理由——拆分的驱动力是业务复杂度与团队协作，不是高并发。单体用缓存、异步、水平扩容三台机器即可扛住 1 万 QPS；只有团队、业务、资源等信号持续恶化（命中 3 个以上）才启动拆分，且拆错的代价远大于晚拆。

⚡记忆卡片

开篇词丨秒杀系统架构设计都有哪些关键点？

秒杀的整体架构可以概括为“稳、准、快”几个关键字

• 稳-高可用 - 服务需要考虑各种容错场景，保证服务可用
• 准-一致性 - 高并发下的库存数量增减不能出错，避免超卖
• 快-高性能 - 支持高并发的读写

设计秒杀系统时应该注意的 5 个架构原则

架构原则：“4 要 1 不要”

• 数据尽量少：减少传输数据量（降低 CPU/带宽）；减少数据库依赖（降低 DB 压力）
• 请求数尽量少：合并 CSS/JS，减少静态资源请求数
• 路径尽量短：减少数据经过的节点数，降低 I/O 传输耗时
• 依赖尽量少：减少完成一次用户请求必须依赖的系统/服务
• 避免单点：
  • 应用服务设计为无状态 + 集群部署
  • 数据库通过副本 + 故障转移保证可用性

RPC 简介

通过注册中心，服务消费者和服务提供者就可以感知彼此。但是，要实现交互还必须解决通信问题。

在单体应用中，一次服务调用发生在同一台机器上的同一个进程内部，因此也被称为本地方法调用。在微服务应用中，由于服务提供者和服务消费者运行在不同物理机器上的不同进程内，因此也被称为远程方法调用，简称 RPC（Remote Procedure Call）。

RPC 是微服务架构的基石，它提供了一种应用间通信的方式。RPC 的主要作用是：

• 屏蔽远程调用跟本地调用的差异，让用户像调用本地一样去调用远程方法。
• 隐藏底层网络通信的复杂性，让用户更聚焦于业务逻辑。

服务注册和发现的基本原理

服务定义是服务提供者和服务消费者之间的约定，但是在微服务架构中，如何达成这个约定呢？这就依赖于服务注册和发现机制。

注册和发现的角色

在微服务架构下，服务注册和发现机制中主要有三种角色：

• 服务提供者（RPC Server / Provider）
• 服务消费者（RPC Client / Consumer）
• 服务注册中心（Registry）