设计该招聘信息推荐平台的高可用架构，需考虑哪些组件（如负载均衡器、主从数据库、缓存层），并说明各组件的作用和容灾方案（如主从切换、数据同步机制）。
国家机关、事业单位招聘信息推荐1月（第三期）电气工程师难度：中等
答案
1) 【一句话结论】
设计招聘信息推荐平台的高可用架构，需通过负载均衡分发请求、主从数据库保障数据持久性、缓存提升性能，并配套健康检查、主从切换、数据同步等容灾机制，实现多级冗余以减少故障影响，确保系统持续可用。
2) 【原理/概念讲解】
高可用架构的核心是“冗余+快速故障切换”，通过多级组件保障服务连续性。
- 负载均衡器：作为请求分发入口，将用户请求分发到多台后端服务器，避免单点故障。需配置健康检查（如Nginx的
upstream health-check参数，通过自定义脚本检查数据库连接状态或查询系统表（如show master status）的响应时间），确保仅将请求发到健康节点。 - 主从数据库：主库处理写操作（如更新推荐数据），从库异步复制主库数据（如MySQL的Binlog复制）。当主库故障时，通过主从切换（如GTID或基于日志的切换）将流量切换到从库，保证数据不丢失。需权衡同步策略：异步复制减少主库压力，但可能数据延迟（适用于写密集型业务）；半同步需从库确认写入，保证数据一致性（适用于对一致性要求高的场景）。
- 缓存层：将热点数据（如热门岗位信息、用户推荐结果）缓存到内存（如Redis），用户请求优先从缓存获取，减少数据库压力。需与数据库数据同步（如通过消息队列或数据库触发器），避免缓存与数据库数据不一致。
3) 【对比与适用场景】
| 组件 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 负载均衡器 | 分发网络请求的设备/软件（如Nginx、HAProxy） | 支持轮询、权重、IP哈希等算法，配置健康检查 | 高并发访问场景（如招聘平台用户访问量大的热门页面） | 需定期检查后端服务器状态，避免故障节点接收请求 |
| 主从数据库 | 主库处理写操作，从库异步复制数据（如MySQL主从） | 数据一致性通过日志同步，支持主从切换 | 需要数据持久性保障的业务（如招聘信息、用户数据） | 异步复制可能导致数据延迟，需评估业务对延迟的容忍度；半同步会增加主库写入延迟 |
| 缓存层（Redis） | 内存数据库，用于存储热点数据 | 高性能读写，支持集群、持久化、事务 | 热点数据（如热门岗位、推荐信息） | 缓存击穿（热点数据失效导致大量数据库查询）和雪崩（缓存大量失效）需防范；需与数据库数据同步 |
4) 【示例】
用户访问“Java工程师”岗位推荐页面：
- 请求首先被负载均衡器（Nginx）分发到后端服务器（如Server A）。
- Server A检查Redis缓存，若缓存有该岗位信息，直接返回；若未命中，查询MySQL主库（写操作：更新推荐数据）。
- 主库将数据写入并同步到从库（异步复制），同时通过消息队列更新Redis缓存（或直接写入Redis）。
- 若主库故障，负载均衡器通过健康检查（检查数据库连接状态）发现主库不可用，切换到从库（如Server B），从库通过GTID或日志恢复数据，继续提供服务。
- Redis集群采用哨兵模式，确保缓存高可用（即使某台Redis节点故障，集群仍能提供服务）。
5) 【面试口播版答案】
设计招聘信息推荐平台的高可用架构，核心是构建多级冗余系统。首先，负载均衡器（如Nginx）负责分发请求，将用户访问分发到多个后端服务器，避免单点故障。然后，主从数据库（如MySQL）保障数据持久性，主库处理写操作，从库异步复制，当主库故障时，通过健康检查（检查数据库连接状态）触发主从切换（如GTID）。缓存层（如Redis）提升性能，将热点数据缓存到内存，用户请求优先从缓存获取。容灾方案上，负载均衡器定期检查后端状态，主从数据库通过日志同步数据，Redis集群用哨兵模式保证高可用。这样即使某台服务器或数据库故障，系统仍能继续提供服务，显著提升可用性。
6) 【追问清单】
- 问：负载均衡器常用的算法有哪些？比如轮询、权重、IP哈希，不同场景如何选择？
答：轮询是均匀分发请求，权重根据服务器性能调整；IP哈希保证同一用户请求固定到同一服务器，适合会话保持场景。 - 问：主从切换的触发条件是什么？比如健康检查的具体指标？
答：通过检查数据库连接状态（如ping数据库）、查询系统表（如show master status）或自定义SQL，若主库响应超时或返回错误，触发切换。 - 问：缓存与数据库的同步策略？比如异步复制还是半同步？
答：异步复制减少主库压力，但可能数据延迟；半同步需从库确认写入，保证数据一致性，适合对一致性要求高的场景。
7) 【常见坑/雷区】
- 坑1：未明确负载均衡器健康检查的具体实现（如未提Nginx health-check参数或自定义脚本检查数据库状态）。
- 坑2：容灾方案细节不够具体（如只说主从切换，未提触发条件和数据同步机制）。
- 坑3：忽略缓存与数据库的同步问题，导致数据不一致（如未提消息队列或触发器同步）。
- 坑4：负载均衡的故障处理，比如未考虑后端服务器故障时的健康检查。
- 坑5：高可用架构的监控告警缺失（如未提如何监控各组件状态，故障时及时告警）。