通用设计题

这是一道典型的系统设计开放题，核心考察的是：

• 如何拆解超大流量、高并发、强一致性场景。
• 如何识别核心链路，例如余票查询、库存扣减、订单创建、支付超时回滚。
• 如何在可用性、性能、一致性之间做取舍。

面试时通常可以从这些方向展开：

1. 流量分层与入口治理，例如 CDN、网关、限流、熔断、降级。
2. 余票查询与缓存设计，例如读写分离、本地缓存、分布式缓存、热点车次隔离。
3. 库存扣减与防超卖，例如分桶、分段锁、排队、消息队列、幂等控制。
4. 订单与支付链路，例如订单状态机、支付回调、超时取消、补偿机制。
5. 数据分片与容灾，例如按地域、车次、日期维度拆分，以及多机房容灾。

这道题重点不在唯一答案，而在于你是否有完整的分层思维。

可以从以下角度回答：

1. 接入层：DNS、CDN、负载均衡、反向代理。
2. 应用层：无状态服务、水平扩容、服务拆分、弹性伸缩。
3. 数据层：主从、分库分表、冷热分离、缓存、搜索引擎。
4. 用户信息存储：区分核心资料、登录鉴权信息、画像信息、行为信息等不同数据类型。
5. 可用性保障：限流、熔断、降级、监控、告警、容灾、备份。

回答时还可以强调：

• 用户量不等于并发量，需要先澄清 DAU、峰值 QPS、读写比例。
• 用户信息设计要结合业务场景，不能只说“放 MySQL”。

这类题考察的是项目管理和沟通协同能力。

回答时可以从下面几个方面展开：

1. 先确认延期原因，是需求膨胀、评估失真、资源不足，还是协作链路有阻塞。
2. 重新拆解任务，区分必须做、可延期做、可并行做的部分。
3. 对插入任务做优先级管理，评估它对原计划的冲击，而不是直接硬塞。
4. 明确同步风险，及时向上游和相关方暴露影响面。
5. 必要时通过范围收缩、资源调整、阶段性交付来守住关键节点。

更稳妥的回答方式不是“我一定保证不延期”，而是：

• 我会先判断是否真的可以不延期。
• 如果不能，就尽早暴露风险，并给出替代方案和可交付边界。

这道题适合按全链路分层回答。

常见回答框架如下：

1. 网络与接入层：带宽、DNS、CDN、静态资源优化、gzip/Brotli。
2. 网关与负载层：负载均衡、反向代理、限流、连接复用。
3. 应用层：无状态设计、缓存、异步化、任务削峰填谷。
4. 数据层：索引优化、读写分离、分库分表、缓存、搜索引擎。
5. 稳定性体系：监控、告警、链路追踪、压测、故障演练、容灾。

如果想答得更成熟，可以补一句：

• “高性能”不是单点优化，而是从静态资源、动态接口、数据访问、系统容量到稳定性治理的一整套工程体系。