机场在高峰时段（如春运）值机系统需处理数万旅客的并发请求，请设计该系统的架构，并说明如何保证系统的高可用性和低延迟。
中国航空集团产品管理岗位难度：困难
答案
1) 【一句话结论】
针对机场高峰值机系统，采用微服务拆分（用户、订单、资源服务）+分布式缓存（Redis）+异步消息队列（Kafka）+数据库分库分表+服务降级熔断的架构，通过负载均衡（Nginx）实现高并发下的低延迟和高可用，关键操作（如座位扣减）通过幂等性机制保证业务正确性。
2) 【原理/概念讲解】
老师口吻解释核心技术点：
- 微服务拆分：按业务边界拆分为用户服务（管理用户信息）、订单服务（处理值机订单）、资源服务（管理座位/资源），独立部署、独立扩展（类比：机场不同部门各司其职，值机、票务、资源管理分别负责，避免一个部门承担所有任务）。
- 分布式缓存（Redis）：缓存热点数据（如热门航班座位、用户信息），减少数据库压力（类比：值机柜台提前准备热门航班座位信息，顾客到柜台即取，无需等待查询）。
- 异步消息队列（Kafka）：解耦服务依赖，座位扣减操作异步处理，失败消息进入死信队列（类比：值机员将座位扣减任务交给后台系统处理，若处理失败，任务进入待处理队列，后续人工或重试处理）。
- 幂等性处理：座位扣减操作需保证重复执行不重复扣减，通过Redis分布式锁（SETNX）或数据库唯一索引实现（类比：顾客多次点击值机按钮，系统通过锁机制确保座位只被扣减一次）。
- 数据库分库分表：对座位表等高并发表水平分片，分散读写压力（类比：机场按航班区域分配值机柜台，每个柜台处理特定航班的座位，避免单个柜台过载）。
- 服务降级/熔断：流量超过阈值时，降级非核心功能（如简化值机流程），熔断故障服务（类比：机场某值机柜台设备故障，暂时不提供该柜台服务，顾客转至其他柜台，避免整体瘫痪）。
3) 【对比与适用场景】
| 架构模式 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 单体架构 | 所有功能模块集中在一个应用中 | 代码耦合度高，扩展困难，故障影响全局 | 小规模系统，开发周期短 | 难以应对高并发，难以独立部署 |
| 微服务架构 | 按业务拆分为多个独立服务 | 模块化，独立部署，高内聚低耦合 | 大规模系统，高并发，业务复杂 | 服务间通信复杂，需处理分布式问题（如网络延迟、数据一致性） |
4) 【示例】（伪代码/请求示例）
用户请求：POST /api/v1/checkin 参数：ticketId=123456, passengerId=1001, flightId=CA1234
流程：
- Nginx负载均衡将请求转发至用户服务实例。
- 用户服务查询Redis缓存用户信息（若未命中，查询数据库并缓存）。
- 用户服务调用订单服务检查座位状态（订单服务查询Redis缓存座位信息，未命中则查询数据库）。
- 订单服务调用资源服务扣减座位（资源服务通过Redis分布式锁实现幂等性，若锁获取失败则返回失败；成功后异步写入Kafka，失败消息进入死信队列）。
- 资源服务处理完成后，通过Kafka通知订单服务，订单服务更新座位状态（超时则触发服务降级，简化值机流程）。
- 订单服务返回结果给用户服务，用户服务返回值机成功信息给前端。
5) 【面试口播版答案】
“面试官您好，针对机场高峰值机系统，我的设计核心是微服务架构配合分布式技术。通过Nginx负载均衡分发请求，Redis缓存热点数据并提前预热，座位扣减异步处理，失败消息进入死信队列，座位表分库分表，K8s集群自动扩缩容，流量超限时降级非核心功能。具体来说，系统拆分为用户、订单、资源服务，座位扣减用Redis锁保证幂等性，数据库分库分表，K8s根据流量扩容实例，这样既能应对数万并发，又能保证系统稳定。”
6) 【追问清单】
- 问题1：如何处理服务间的通信延迟？
回答要点：采用gRPC长连接减少连接建立时间，异步通信（消息队列）避免请求阻塞，服务间设置5秒超时，超时后重试或降级。 - 问题2：缓存击穿、雪崩如何应对？
回答要点：缓存击穿用Redis互斥锁（SETNX）保证热点数据只被一个线程加载；缓存雪崩用随机过期时间或预加载热点数据；同时设置缓存预热机制。 - 问题3：数据一致性如何保证？
回答要点：座位扣减采用最终一致性（消息队列异步通知），关键数据（如座位状态）用Seata分布式事务保证强一致性；通过监控告警及时发现数据不一致。 - 问题4：系统扩展性如何？
回答要点：微服务支持水平扩展，K8s集群根据请求量自动扩容实例；数据库分库分表支持水平扩展；缓存集群和消息队列分区扩容，提高吞吐量。
7) 【常见坑/雷区】
- 坑1：忽略请求幂等性：座位扣减重复操作会导致业务问题，需在缓存/数据库添加唯一标识（如UUID）避免。
- 坑2：无缓存预热机制：首次访问延迟高，影响用户体验，需系统启动时预加载热点数据。
- 坑3：未设计死信队列：消息队列失败消息无处理机制，可能导致数据丢失，需设置死信队列人工/重试处理。
- 坑4：绝对化表述：如“实现高可用与低延迟”，需结合具体技术细节说明，避免夸大能力。
- 坑5：微服务拆分边界不清晰：按技术边界拆分（如按模块），而非业务边界，导致服务间耦合度高，扩展困难。