综合场景面试题#
1. 千万级商城系统架构设计#
问题： 假设我们要部署一个日活千万级的商城系统，请画出从 DNS -> CDN -> Nginx -> K8s(Java App) -> Redis -> MySQL 的全链路架构，并说明每一层的容灾方案。
答案：
架构图#
用户请求
│
▼
┌─────────────────────────────────────────────────────────────┐
│ DNS 层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ DNSPod │ │ Cloudflare │ │ Route53 │ │
│ │ (主) │ │ (备) │ │ (备) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ 智能解析 + 故障转移 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ CDN 层 │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 阿里云 CDN │ │ 腾讯云 CDN │ │ CloudFront │ │
│ │ (静态资源) │ │ (静态资源) │ │ (静态资源) │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ 静态资源缓存 + DDoS 防护 + 就近访问 │
└─────────────────────────────────────────────────────────────┘
│
▼ (动态请求)
┌─────────────────────────────────────────────────────────────┐
│ 接入层 (L7) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Nginx 集群 │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Nginx 1 │ │ Nginx 2 │ │ Nginx 3 │ + Keepalived │ │
│ │ │ (Master)│ │(Backup) │ │(Backup) │ (VIP漂移) │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ 负载均衡 + SSL 卸载 + 限流 + WAF │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 应用层 (K8s) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Kubernetes 集群 │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Node 1 │ │ Node 2 │ │ Node 3 │ │ │
│ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ │
│ │ │ │ Java Pod│ │ │ │ Java Pod│ │ │ │ Java Pod│ │ │ │
│ │ │ │ x3 │ │ │ │ x3 │ │ │ │ x3 │ │ │ │
│ │ │ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │ │ │
│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │
│ │ HPA 自动扩缩容 + 多可用区部署 + 健康检查 │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 缓存层 (Redis) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Redis Cluster 集群 │ │
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
│ │ │ Master 1│ │ Master 2│ │ Master 3│ │ │
│ │ │ Slave 1 │ │ Slave 2 │ │ Slave 3 │ │ │
│ │ └─────────┘ └─────────┘ └─────────┘ │ │
│ │ 6 节点集群 + 读写分离 + 自动故障转移 │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
│ (缓存未命中)
▼
┌─────────────────────────────────────────────────────────────┐
│ 数据库层 (MySQL) │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ MySQL 主从集群 │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Master │─────▶│ Slave 1 │ │ │
│ │ │ (写 + 读) │ │ (只读) │ │ │
│ │ │ + MHA │─────▶│ Slave 2 │ │ │
│ │ │ │ │ (只读) │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ │ 主从复制 + MHA 高可用 + 读写分离 │ │
│ └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘各层容灾方案#
| 层级 | 容灾方案 | 说明 |
|---|---|---|
| DNS | 多 DNS 服务商 | DNSPod + Cloudflare，故障时切换 |
| CDN | 多 CDN 厂商 | 阿里云 + 腾讯云，智能调度 |
| Nginx | Keepalived + VIP | Master 故障，VIP 自动漂移到 Backup |
| K8s | 多可用区 + HPA | 跨 AZ 部署，自动扩缩容 |
| Redis | Cluster 模式 | 6 节点集群，自动故障转移 |
| MySQL | MHA + 主从 | 主库故障，30 秒内自动切换 |
监控告警#
# 关键指标监控
- 应用层: QPS, 响应时间, 错误率
- 缓存层: 命中率, 连接数, 内存使用
- 数据库: 主从延迟, 慢查询, 连接数
- 基础设施: CPU, 内存, 磁盘, 网络2. 系统全链路压测方案#
问题： 如何对千万级商城系统进行全链路压测？
答案：
压测策略：
1. 单接口压测 → 2. 单链路压测 → 3. 全链路压测 → 4. 混沌测试压测环境：
生产环境影子库方案：
- 写操作 → 影子库（不污染真实数据）
- 读操作 → 缓存 + 影子库
- 标记压测流量（Header: X-Test-Flag: 1）压测工具链：
# 负载生成
JMeter / Gatling / Locust / k6
# 流量控制
TC (Traffic Control) - 模拟网络延迟、丢包
# 监控
Prometheus + Grafana + APM (SkyWalking/Pinpoint)
# 日志分析
ELK (Elasticsearch + Logstash + Kibana)压测指标：
| 指标 | 目标 |
|---|---|
| QPS | 10万+/秒 |
| 平均响应时间 | < 200ms |
| P99 响应时间 | < 500ms |
| 错误率 | < 0.1% |
| CPU 使用率 | < 70% |
| 内存使用率 | < 80% |
3. 线上故障应急处理#
问题： 线上商城系统突然不可用，你的应急处理流程是什么？
答案：
应急流程（1-5-10 原则）：
1 分钟：发现问题（监控告警）
5 分钟：定位问题（快速止损）
10 分钟：恢复服务（故障解决）处理步骤：
# 1. 确认故障范围
- 是全国还是部分地区？
- 是所有功能还是部分功能？
- 是全部用户还是部分用户？
# 2. 快速止损（优先恢复服务）
# 方案1：回滚
kubectl rollout undo deployment/app
# 方案2：降级
# - 关闭非核心功能（推荐、评论）
# - 切换静态页面
# - 限流
# 方案3：扩容
kubectl scale deployment app --replicas=20
# 3. 定位根因
# - 查看日志
# - 查看监控
# - 查看变更记录
# 4. 修复并验证
# - 修复问题
# - 灰度发布
# - 全量发布
# 5. 复盘总结
# - 故障报告
# - 改进措施
# - 更新预案故障等级：
| 等级 | 影响 | 响应时间 | 处理要求 |
|---|---|---|---|
| P0 | 系统不可用 | 5 分钟 | 全员响应 |
| P1 | 核心功能受损 | 15 分钟 | 核心团队 |
| P2 | 非核心功能异常 | 1 小时 | 正常排期 |
| P3 | 轻微问题 | 1 天 | 下个迭代 |
4. 数据迁移方案#
问题： 如何将一个 10TB 的 MySQL 数据库从旧机房迁移到新机房，要求停机时间 < 5 分钟？
答案：
迁移方案：
阶段1：全量同步（提前执行）
阶段2：增量同步（持续同步）
阶段3：切换（停机 5 分钟内完成）详细步骤：
# 1. 全量备份（提前1天）
mysqldump --single-transaction --master-data=2 \
-h old-master -u root -p db_name > full_backup.sql
# 2. 导入新库
mysql -h new-master -u root -p db_name < full_backup.sql
# 3. 配置主从同步（旧库 -> 新库）
# 获取 binlog 位置
cat full_backup.sql | grep "CHANGE MASTER"
# 在新库执行
CHANGE MASTER TO
MASTER_HOST='old-master',
MASTER_USER='repl',
MASTER_PASSWORD='password',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=1234;
START SLAVE;
# 4. 验证同步延迟
SHOW SLAVE STATUS\G
# Seconds_Behind_Master = 0 表示同步完成
# 5. 切换（停机窗口）
# 5.1 停止应用写入
# 5.2 确认同步完成
# 5.3 新库提升为主库
STOP SLAVE;
RESET SLAVE ALL;
# 5.4 应用切换到新库
# 修改应用配置，重启连接池
# 5.5 验证
# 检查数据一致性
# 检查应用功能
# 6. 回滚方案（如果失败）
# 切回旧库，重新同步数据一致性校验：
# 使用 pt-table-checksum 校验数据
pt-table-checksum \
--host=old-master \
--replicate=percona.checksums \
--databases=db_name \
--recursion-method=processlist
# 查看差异
pt-table-sync --print --execute h=old-master,h=new-master --databases=db_name5. 安全攻防演练#
问题： 如何对运维体系进行安全攻防演练？
答案：
攻击面分析：
1. 网络层：DDoS、中间人攻击
2. 主机层：漏洞利用、权限提升
3. 应用层：SQL 注入、XSS、CSRF
4. 数据层：数据泄露、勒索软件
5. 供应链：依赖包漏洞演练方案：
# 1. 信息收集
nmap -sV -O target.com
subfinder -d target.com
# 2. 漏洞扫描
nessus / openvas / awvs
# 3. 渗透测试
# - 弱口令爆破
hydra -l admin -P passwords.txt ssh://target.com
# - SQL 注入
sqlmap -u "http://target.com/search?q=test"
# - 命令注入
curl "http://target.com/exec?cmd=cat+/etc/passwd"
# 4. 内网渗透
# - 横向移动
# - 权限提升
# - 数据窃取
# 5. 痕迹清理
# - 日志清理
# - 后门植入防御加固：
# 1. 网络隔离
# - VPC 划分
# - 安全组规则
# - WAF 防护
# 2. 主机加固
# - 最小化安装
# - 定期补丁
# - HIDS (OSSEC)
# 3. 应用安全
# - 代码审计
# - SAST/DAST
# - RASP
# 4. 数据安全
# - 加密存储
# - 访问控制
# - 审计日志
# 5. 应急响应
# - 监控告警
# - 应急预案
# - 定期演练6. 成本控制与优化#
问题： 如何优化千万级系统的云资源成本？
答案：
成本分析：
典型成本分布：
- 计算资源：40%
- 存储资源：30%
- 网络流量：20%
- 其他：10%优化策略：
| 资源 | 优化方案 | 预期节省 |
|---|---|---|
| 计算 | Spot 实例 + 自动扩缩容 | 50-70% |
| 存储 | 冷热分层 + 压缩 | 40-60% |
| 网络 | CDN + 内网传输 | 30-50% |
| 数据库 | Serverless + 归档 | 30-40% |
FinOps 实践：
# 1. 标签管理
# 所有资源打标签
Team: backend
Project: mall
Environment: production
# 2. 成本分摊
# 按团队/项目分摊成本
# 3. 预算告警
# 月度预算 100万，超过 80% 告警
# 4. 资源回收
# 自动清理闲置资源
# - 未使用的 EIP
# - 未挂载的云盘
# - 过期的快照