平台需要应对高峰访问（如招聘季），请设计系统的架构以保障高可用和低延迟，包括前端、后端、数据库层面的优化措施。

1) 【一句话结论】通过分层架构（前端负载均衡+后端微服务集群+数据库读写分离+缓存+CDN）结合自动化扩缩容，并引入健康检查、故障转移等高可用机制，同时通过缓存策略应对数据库压力，实现高可用与低延迟。

2) 【原理/概念讲解】老师口吻：高可用（HA）是指系统故障时仍能提供服务，低延迟是响应时间短。负载均衡（LB）像交通枢纽，分发请求到多个服务器，常用Nginx、LVS，通过健康检查确保只转发健康节点。微服务是将系统拆分为独立服务，独立部署，提高可扩展性。缓存（如Redis）是临时存储热点数据，减少数据库压力。数据库读写分离是将读操作分到从库，写操作到主库，提升读性能。CDN是边缘节点缓存静态资源，减少源站压力。扩缩容通过K8s自动调整实例数量。

3) 【对比与适用场景】

方案	定义	特性	使用场景	注意点
负载均衡算法（加权轮询）	根据节点性能权重分发请求	考虑节点负载差异	节点性能不均的场景	权重需准确计算，避免低性能节点过载
负载均衡算法（一致性哈希）	根据请求哈希值分配节点	节点增删时流量平滑	节点动态变化场景	需维护哈希环一致性
缓存方案（单机Redis）	单节点存储数据	简单易用	小规模应用，数据量不大	单点故障，无法扩展
缓存方案（分布式Redis集群）	多节点存储数据，集群管理	可扩展、高可用	大规模应用，数据量大	需维护数据一致性（如双写）
数据库分库分表策略（垂直分库）	按业务模块拆分数据库	模块独立	业务模块复杂，数据量差异大	模块间数据关联需跨库查询
数据库分库分表策略（水平分表）	按数据范围拆分表	提升单表性能	单表数据量过大	需分片规则，查询需路由

4) 【示例】用户访问招聘平台，请求路径：前端Nginx负载均衡器（检查后端服务器健康状态，如通过HTTP 200响应），分发请求到后端服务（如用户服务）。后端服务检查Redis缓存（热点数据如热门职位列表），若命中则返回；否则查询数据库主库（写操作），并将结果同步到从库，同时更新缓存（Redis）。数据库主从复制，从库提供读操作。CDN边缘节点缓存静态资源（如网页、图片），用户请求先到CDN，若未命中则回源到源站。高峰时，K8s根据CPU使用率自动增加后端实例数量，数据库从库数量同步增加，缓存预热热门数据。

5) 【面试口播版答案】面试官您好，针对平台应对高峰访问的需求，我设计的系统架构核心是通过分层架构结合自动化扩缩容，并重点保障高可用与低延迟。具体来说，前端部署Nginx负载均衡器，通过健康检查（如Ping或HTTP 200响应）确保只转发健康后端服务器，将请求分发到后端微服务集群；后端通过Kubernetes管理多实例服务，数据库层采用主从复制+读写分离（主库处理写操作，从库处理读操作），并引入Redis集群缓存热点数据（如热门职位信息、用户登录信息）；同时结合CDN边缘节点缓存静态资源（如网页、图片），减少源站压力。高峰时，通过K8s的Horizontal Pod Autoscaler自动扩容后端实例和数据库从库，Redis缓存缓解数据库压力，负载均衡分散流量，最终实现高可用（故障时自动切换）和低延迟（缓存+读写分离+CDN）。

6) 【追问清单】

• 负载均衡的健康检查具体机制？答：采用定期Ping健康节点（如每秒一次），若响应超时或返回非200，则标记为不健康，停止转发请求。
• 缓存击穿/雪崩的解决方案？答：缓存击穿用互斥锁（分布式锁，如Redis SETNX）保证仅一个线程查询数据库并更新缓存；缓存雪崩用随机过期时间（避免集中过期）或热点数据预加载（提前加载到缓存）。
• 数据库分库分表的具体策略？答：按业务模块分库（如招聘信息库、用户库），按时间或ID分表（如招聘信息表按发布时间分表，用户表按注册时间分表），结合ShardingSphere实现分片规则。
• 故障转移流程？答：主节点故障时，负载均衡器通过健康检查检测到后端服务器不健康，自动切换到其他健康节点，实现故障转移。

7) 【常见坑/雷区】

• 忽略健康检查：导致负载均衡转发故障节点，影响服务可用性。
• 缓存未考虑数据一致性：如缓存与数据库数据不同步，导致数据不一致。
• 数据库只说读写分离，未提分库分表：在高并发下数据库单库压力仍大。
• CDN未部署：静态资源压力源站，增加延迟。
• 扩缩容机制不明确：高峰时无法自动应对流量，导致服务崩溃。