请设计一个招聘信息推荐系统的高可用架构，包括负载均衡、主从复制、缓存策略等，确保系统在部分组件故障时仍能保持稳定运行。
答案
1) 【一句话结论】采用分层高可用架构，通过前端负载均衡、应用层负载均衡、多级缓存（本地+分布式）与数据库主从复制，结合故障隔离、自动切换及容灾机制，确保系统在部分组件故障时仍能稳定运行（假设故障率低于5%，恢复时间小于5秒）。
2) 【原理/概念讲解】老师口吻，先讲分层架构逻辑：系统设计需从“请求入口-业务处理-数据存储”分层设计，每层通过冗余和容灾保障高可用。
- 负载均衡：前端用Nginx实现四层/七层负载均衡，支持轮询、哈希、会话保持算法，将流量分发到多台应用服务器；应用层用Ribbon配合服务注册中心（如Eureka），实现客户端动态负载均衡，动态调整流量。
- 多级缓存：采用“本地缓存（如Guava Cache）+分布式缓存（如Redis集群）”分层策略。本地缓存缓存高频访问的热点数据（如用户常用推荐标签），减少分布式缓存压力；分布式缓存缓存共享热点数据（如热门职位信息），提升并发能力。缓存策略需应对三类问题：
- 缓存穿透：使用布隆过滤器过滤无效key（如空用户ID），避免查询数据库；
- 缓存击穿：对热点key设置互斥锁+过期时间（如Redis的SET key EX 60 NX），防止并发请求穿透缓存；
- 缓存雪崩：通过随机TTL（避免同一时间大量key过期）、分布式锁（控制并发写入）、热点key预加载（提前缓存热门数据，如每日热门职位），降低雪崩风险。
- 主从复制：数据库选MySQL主从复制，主库负责写操作，从库负责读操作。同步复制适合强一致性场景（如金融交易），异步复制适合高并发场景（如推荐系统），需监控主从延迟（如使用pt-heartbeat工具，阈值设为1秒），当延迟超过阈值时，暂停从库读操作或切换到其他从库。
- 容灾机制：通过健康检查（如Ping应用服务器、查询数据库状态）实现自动故障切换。某台应用服务器故障时，负载均衡器自动将流量切换到其他正常服务器（切换时间小于5秒）；MySQL主库故障时，从库自动提升为主库，继续提供服务。
3) 【对比与适用场景】
| 方案类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 负载均衡（Nginx） | 开源反向代理服务器 | 支持轮询、哈希、会话保持等算法，高并发处理能力强 | 前端负载均衡，应用层负载均衡 | 配置会话保持时需配合Session共享（如Redis Session） |
| 负载均衡（Ribbon） | Spring Cloud组件 | 实现客户端动态负载均衡，支持轮询、随机、权重算法 | 应用层负载均衡，微服务调用 | 需配合服务注册中心（如Eureka）实现服务发现 |
| 主从复制（同步） | 主库写操作同步到从库 | 数据一致性高，延迟低 | 金融、交易等强一致性系统 | 性能受影响，主库压力较大 |
| 主从复制（异步） | 主库写操作异步到从库 | 性能高，延迟高 | 推荐系统、电商等高并发系统 | 可能存在数据延迟，需监控延迟 |
| 缓存策略（LRU） | 最近最少使用 | 淘汰最久未使用的key | 热点数据缓存 | 需定期调整缓存大小，避免冷数据占用空间 |
| 缓存策略（TTL） | 过期时间 | 设置key的存活时间 | 不常变动的数据 | 需合理设置TTL，避免频繁过期导致缓存雪崩 |
| 缓存策略（多级） | 本地缓存+分布式缓存 | 本地缓存优先级最高，分布式缓存补充 | 高并发、高可用系统 | 需设计缓存穿透、击穿、雪崩的应对方案 |
4) 【示例】
系统架构：前端负载均衡（Nginx）→ 应用层负载均衡（Ribbon）→ 应用服务器集群（多台）→ 本地缓存（Guava Cache）→ 分布式缓存（Redis集群）→ MySQL主从复制（主库+从库）。
请求流程（伪代码）：
用户请求到达Nginx负载均衡器
Nginx根据会话保持规则将请求转发到某台应用服务器
应用服务器首先检查本地缓存（key为“user_id:recommendations”）
- 若存在，直接返回缓存数据
- 若不存在，检查Redis缓存（key为“user_id:recommendations”）
- 若存在，返回缓存数据
- 若不存在，查询MySQL主库（SELECT * FROM recommendations WHERE user_id = ?）
- 执行SQL后，将结果存入本地缓存（SET key value EX ttl）和Redis缓存（SET key value EX ttl）
- 返回数据给用户
故障场景：某台应用服务器故障，Nginx通过健康检查（Ping应用服务器）发现故障，自动将流量切换到其他正常服务器；MySQL主库故障，从库自动提升为主库，继续提供服务。
5) 【面试口播版答案】
面试官您好，针对物理专业助理岗位的招聘信息推荐系统高可用架构设计，我会从分层架构、核心组件选型与容灾机制三方面展开。整体采用“前端负载均衡+应用层负载均衡+多级缓存+数据库主从复制”的分层设计，确保各层故障时能隔离影响。负载均衡方面，前端用Nginx实现会话保持的轮询调度，应用层用Ribbon实现动态负载均衡；主从复制选MySQL主从，主库写操作同步到从库保证一致性；缓存策略采用本地缓存（Guava）+分布式缓存（Redis），本地缓存缓存高频访问数据，分布式缓存缓存共享热点数据。容灾机制上，通过健康检查（Ping应用服务器、查询数据库状态）实现自动故障切换，比如某台应用服务器故障时，负载均衡器自动将流量切换到其他正常服务器，数据库主库故障时，从库自动提升为主库。多级缓存中，本地缓存优先级最高，若本地无则查询分布式缓存，再查数据库，减少数据库压力。这样即使部分组件故障，系统仍能保持稳定运行（假设故障率低于5%，恢复时间小于5秒）。
6) 【追问清单】
- 如何处理缓存雪崩问题？
回答要点：通过设置随机TTL（避免同一时间大量key过期）、分布式锁（控制并发写入）、热点key预加载（提前缓存热门数据）。 - 数据库主从复制延迟如何解决？
回答要点：监控主从延迟（如使用pt-heartbeat工具），当延迟超过阈值时，暂停从库读操作，或切换到其他从库；定期同步数据。 - 多级缓存的切换逻辑是什么？
回答要点：本地缓存命中则直接返回，否则查询分布式缓存，再查询数据库，减少数据库压力。 - 容灾的边界条件是什么？
回答要点：故障率低于5%，恢复时间小于5秒（如应用服务器故障时，切换时间小于5秒）。 - 数据一致性如何保障？
回答要点：使用乐观锁（更新时检查版本号）、最终一致性（允许短暂不一致，通过重试机制解决）。
7) 【常见坑/雷区】
- 忽略缓存雪崩应对，系统在缓存失效时崩溃。
- 主从复制只说同步没提异步的权衡，显得对技术细节不深入。
- 缓存穿透未提布隆过滤器，导致无效key查询数据库。
- 负载均衡未提会话保持，导致会话丢失影响用户体验。
- 缺少健康检查机制，故障时无法自动切换，导致服务不可用。