设计一个校园招聘会的线上系统，在高峰时段（如1000+企业同时发布职位，10000+学生同时浏览），如何保证系统稳定性和响应速度？
成都理工大学就业指导中心训练专员（飞行部）难度：困难
答案
1) 【一句话结论】采用微服务架构结合分布式技术（负载均衡、缓存、消息队列、数据库分库分表），通过水平扩展、资源隔离和请求削峰填谷，确保高并发下系统稳定且响应迅速。
2) 【原理/概念讲解】高并发系统设计核心是“水平扩展”与“解耦”，避免单点故障。
- 负载均衡：将请求分发到多台服务器，如Nginx的轮询或哈希算法，避免单机过载。类比：餐厅服务员分桌，高峰时多服务员同时服务。
- 缓存：将热点数据（如热门企业、职位）存入Redis等内存数据库，减少数据库查询压力。类比：超市预存畅销商品，顾客直接拿，无需排队。
- 消息队列：企业发布职位时，通过RabbitMQ/Kafka将消息推送给多个消费者（推荐、通知等），解耦发布与消费，避免高并发直接冲击数据库。类比：快递分拣中心，包裹先入队列，分拣员按顺序处理。
- 数据库分库分表：将用户表、职位表等按业务或ID分片存储，如用户表按ID模3分3库，减少单库压力。类比：图书馆按书籍分类分馆，查找书籍更快。
3) 【对比与适用场景】
| 技术/组件 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 负载均衡（如Nginx） | 分发请求到多台后端服务器 | 轮询、哈希、IP哈希等算法 | 应用服务器集群 | 需考虑会话粘性（如用户登录状态） |
| 缓存（如Redis） | 内存数据库，存储热点数据 | 高速读写，支持数据过期 | 热门职位、企业信息 | 需设置过期策略，避免数据不一致 |
| 消息队列（如RabbitMQ） | 异步通信中间件 | 解耦、削峰填谷、持久化 | 职位发布、推荐通知 | 需考虑死信队列处理失败消息 |
| 数据库分库分表 | 水平切分数据库表 | 分库（按业务）+分表（按ID） | 用户表、职位表等 | 跨库查询复杂，需优化SQL |
4) 【示例】（伪代码）：
用户访问职位列表（URL：/jobs）：
- 请求到达负载均衡器（Nginx），按轮询分发到应用服务器（如Server1, Server2）。
- 应用服务器检查Redis缓存（Key：
hot_jobs），若存在热门职位数据，直接返回；否则查询数据库（SQL：SELECT * FROM job WHERE status=1），将结果存入Redis（TTL=60秒），返回给用户。
企业发布职位（POST /jobs）： - 请求先入RabbitMQ队列（Topic：
job_publish）。 - 消费者1（推荐系统）消费消息，更新推荐数据；消费者2（通知服务）发送企业通知。
- 数据库操作：通过分库分表（如职位表按企业ID分表），插入新职位记录。
5) 【面试口播版答案】
“面试官您好，针对高并发场景，我会从架构分层和关键技术点入手。首先，通过负载均衡（如Nginx轮询）分发请求到多台应用服务器，避免单机过载。其次，对热点数据（如热门企业、职位）使用Redis缓存，减少数据库压力，比如热门职位列表直接从缓存读取，响应更快。然后，企业发布职位时通过消息队列（RabbitMQ）解耦，避免高并发直接冲击数据库，消息先入队列，由消费者异步处理。最后，数据库通过分库分表（如用户表按ID模3分库），水平切分数据，提升查询性能。这些技术结合水平扩展，能保证系统在高并发下稳定且响应迅速。”
6) 【追问清单】
- 问：负载均衡选Nginx还是LVS？
回答：Nginx配置灵活，适合动态调整；LVS性能更高，适合大规模集群。 - 问：缓存如何避免数据不一致？
回答：设置缓存过期时间（如60秒），同时数据库更新时删除缓存（Cache-aside模式）。 - 问：消息队列选RabbitMQ还是Kafka？
回答：RabbitMQ适合小规模、可靠传输；Kafka适合大规模、持久化存储。 - 问：数据库分库分表后，跨库查询怎么办？
回答：优化SQL（如分库后用连接查询），或使用中间件（如MyCat）。 - 问：如何保证系统容灾？
回答：负载均衡器配置健康检查，应用服务器集群部署，数据库主从复制。
7) 【常见坑/雷区】
- 垂直扩展代替水平扩展：只提升单机性能，成本高且无法应对持续增长流量。
- 缓存未设置过期策略：导致数据过时，影响用户体验。
- 消息队列未考虑死信队列：失败消息堆积，影响系统稳定性。
- 数据库分库分表未考虑读写分离：高并发下读操作仍可能卡库。
- 忽略网络延迟：分布式系统需考虑跨节点通信延迟，优化请求路径。