在大促期间，系统（WMS、TMS）可能面临高并发压力，如何确保系统稳定运行，并快速恢复故障？
答案
1) 【一句话结论】通过负载均衡分散请求、缓存热点数据、自动化监控实时告警、容器化自愈机制，确保系统在高并发下稳定运行，并实现故障的快速检测与自动/手动恢复。
2) 【原理/概念讲解】老师口吻，解释高并发下的系统压力点及解决方案：
高并发时，系统易出现请求积压、资源瓶颈（CPU/内存/数据库连接数超限），导致响应延迟或超时。需通过负载均衡将请求分发至多台服务器，避免单点过载（类比：交通路口信号灯，分散车流）；缓存（如Redis）存储热点数据（如库存、订单），减少数据库查询压力（类比：超市货架，热销商品前置，减少仓库取货时间）；自动化监控（如Prometheus+Grafana）实时收集指标（CPU、内存、连接数），超阈值自动告警（邮件/短信），快速定位问题；容器化自愈（如K8s），服务实例宕机时自动重启容器并重新分配流量，实现快速恢复。
3) 【对比与适用场景】
| 策略类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 负载均衡 | 分发请求至多台服务器 | 提高并发处理能力 | 高流量场景（如大促） | 需考虑会话粘性（如用户登录后请求始终到同一服务器） |
| 缓存策略 | 存储热点数据 | 减少数据库压力 | 热点数据访问（如商品信息） | 需处理缓存穿透（布隆过滤器）、雪崩（随机过期时间） |
| 自动化监控 | 实时监控并自动告警 | 快速发现异常 | 7x24系统监控 | 需合理设置告警阈值（避免误报/漏报） |
| 容灾备份 | 备份数据与配置 | 快速恢复 | 灾难场景（如机房故障） | 需定期演练（测试恢复时间RTO） |
4) 【示例】
- 负载均衡配置（Nginx）：
upstream wms_servers {
server 192.168.1.1:8080;
server 192.168.1.2:8080;
server 192.168.1.3:8080;
}
server {
listen 80;
location / {
proxy_pass http://wms_servers;
proxy_cookie_name JSESSIONID;
proxy_cookie_domain .wms.boxmart.com;
}
}
- 缓存逻辑（Redis）：
# 读取库存，优先查缓存
if redis get stock:1001 exists:
stock = value
else:
stock = db.query("SELECT stock FROM goods WHERE id=1001")
redis set stock:1001 $stock
redis expire stock:1001 300
return stock
- 容器自愈（K8s）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: wms-deployment
spec:
replicas: 3
selector:
matchLabels:
app: wms
template:
metadata:
labels:
app: wms
spec:
containers:
- name: wms
image: wms:latest
restartPolicy: Always
当wms pod宕机，K8s自动创建新pod并重新分配流量。
5) 【面试口播版答案】
在大促期间，系统稳定的核心策略是“预防性措施+快速响应机制”。首先，通过负载均衡（如Nginx或K8s Service）将高并发请求分散到多台服务器，避免单点过载；其次，对热点数据（如商品库存、订单信息）使用Redis缓存，减少数据库查询压力，比如设置缓存过期时间，并实现缓存穿透（布隆过滤器）、雪崩（随机过期时间）的防护；然后，部署自动化监控（如Prometheus+Grafana），实时监控CPU、内存、数据库连接数等指标，当指标超过阈值时，自动触发告警（邮件、短信），帮助快速定位问题；对于故障恢复，采用K8s自愈机制，当服务实例宕机，K8s会自动重启容器并重新分配流量，同时，定期进行容灾演练（如模拟数据库故障），测试备份恢复时间（RTO），确保故障后能在分钟级恢复系统。总结来说，通过负载均衡、缓存、自动化监控和容器化自愈，既能应对高并发压力，又能快速恢复故障。
6) 【追问清单】
- 问题1：如果系统出现数据库慢查询，如何处理？
回答要点：分析慢查询日志，优化SQL语句（如添加索引、调整分页逻辑），或调整数据库参数（如增加连接数、优化缓存大小）。 - 问题2：容灾备份的RTO和RPO分别是什么？
回答要点：RTO（恢复时间目标）是故障后系统恢复的时间，通常要求分钟级；RPO（恢复点目标）是数据丢失的最大量，通常要求秒级或分钟级，需根据业务重要性设置。 - 问题3：如果负载均衡出现故障，如何处理？
回答要点：配置多活负载均衡器（如备用Nginx实例），或手动切换到备用服务器，确保请求不中断。 - 问题4：缓存与数据库数据一致性问题如何解决？
回答要点：使用缓存穿透（布隆过滤器过滤无效请求）、缓存雪崩（随机过期时间避免集中过期）、缓存击穿（互斥锁或分布式锁保证数据一致性）。 - 问题5：自动化监控的告警阈值如何设置？
回答要点：基于历史数据，设置合理的阈值（如CPU使用率超过80%时告警），避免误报（如频繁告警）或漏报（如指标未超过阈值但实际已异常）。
7) 【常见坑/雷区】
- 坑1：仅强调监控工具，未具体说明如何通过监控指标快速定位问题（如只说“用Prometheus监控”，未提具体指标）。
- 坑2：忽略缓存优化细节（如未提及缓存穿透、雪崩防护），导致系统因缓存问题崩溃。
- 坑3：故障恢复时间过长（未考虑容灾演练），实际故障时恢复慢，影响业务。
- 坑4：负载均衡配置不当（如会话粘性设置错误），导致用户登录后切换服务器，会话丢失。
- 坑5：未考虑数据库分库分表，导致高并发下数据库压力过大，系统崩溃。