为机场的旅客服务系统（值机、安检、行李处理）设计高可用架构，确保在单点故障时系统仍能正常运行，请说明关键组件和容灾方案。
中国航空集团信息安全岗位难度：困难
答案
1) 【一句话结论】为机场旅客服务系统设计高可用架构，需通过分布式集群、负载均衡、数据库复制及消息队列解耦，实现多活部署与故障自动切换，确保单点故障时系统仍能正常运行。
2) 【原理/概念讲解】高可用架构的核心是“冗余”与“解耦”，通过多节点部署避免单点故障。关键组件及原理如下：
- 负载均衡器：如Nginx，负责分发请求到后端应用服务器，通过健康检查确保只将请求发送到健康节点，类似机场的调度中心，根据航班状态（健康）分配旅客到空闲柜台。
- 应用服务器集群：采用主备或主主模式，主节点处理请求，备节点热备，当主节点故障时，通过心跳检测自动切换，类似值机柜台，正常时多个柜台同时服务，故障时其他柜台接替。
- 数据库复制：主从复制（主库写，从库读；主库故障时从库提升为主库），或多主复制（读写分离），保证数据一致性，类似行李信息，主库记录最新状态，从库同步，故障时从库接管。
- 消息队列：如Kafka，用于异步处理非核心任务（如行李信息处理、通知发送），解耦应用与任务，避免阻塞主流程，类似机场的行李传送带，主流程（值机）完成后，异步处理行李信息，不影响值机速度。
- 故障检测与自动切换：通过心跳（如心跳包、状态检查）检测节点健康，故障时自动切换到备用节点，确保服务连续性。
3) 【对比与适用场景】以负载均衡器与数据库复制为例，用表格对比：
| 组件 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 负载均衡器 | 分发请求到后端服务器，实现请求负载均衡 | 支持轮询、权重、健康检查等算法 | 高并发场景，如值机系统 | 需配置健康检查，避免将请求发送到故障节点 |
| 数据库主从复制 | 主库写操作，从库读操作，主库故障时从库提升为主库 | 读写分离，提高读性能，故障时自动切换 | 对数据一致性要求高的系统 | 需保证数据同步延迟，避免数据不一致 |
| 数据库多主复制 | 多个节点均可读写，通过一致性协议（如Paxos）保证数据一致 | 读写性能高，故障时自动选举主节点 | 高并发读写场景 | 实现复杂，需考虑冲突解决 |
4) 【示例】架构描述：
- 前端：用户通过浏览器访问，请求首先到达负载均衡器（Nginx）。
- 负载均衡器：检查后端应用服务器的健康状态（如HTTP健康检查），将请求分发到健康的应用服务器。
- 应用服务器：应用服务器集群（如3台服务器，1主2备），主节点处理值机请求，从库热备。主节点从数据库主库读取旅客信息，写入从库；异步任务（如行李信息处理）通过消息队列（Kafka）发送。
- 数据库：主从复制，主库（如MySQL主库）处理写操作，从库（如MySQL从库）处理读操作，主库故障时，从库通过心跳检测提升为主库。
- 消息队列：Kafka集群，处理异步任务，如行李信息发送通知，确保即使应用服务器故障，消息队列仍能存储任务，后续恢复后处理。
伪代码示例（请求流程）：
用户请求：/checkin?ticketId=123
1. 负载均衡器（Nginx）检查应用服务器1健康状态（健康）
2. 将请求转发到应用服务器1
3. 应用服务器1从数据库主库读取旅客信息（SELECT * FROM passengers WHERE ticketId=123）
4. 应用服务器1将值机结果写入数据库从库（INSERT INTO checkin_results...）
5. 应用服务器1将行李信息发送到Kafka（生产者发送消息到topic:baggage）
6. 用户收到值机成功响应
当应用服务器1故障时：
- 负载均衡器检测到应用服务器1不健康（心跳超时）
- 将请求转发到应用服务器2（备节点）
- 应用服务器2从数据库从库读取数据（因为主库故障，从库已提升为主库）
- 处理请求，返回结果
5) 【面试口播版答案】面试官您好，为机场旅客服务系统设计高可用架构，核心是构建分布式集群，通过负载均衡分发请求，结合数据库主从复制和消息队列解耦，实现故障自动切换。具体来说，前端部署负载均衡器（如Nginx），将请求分发到多台应用服务器集群，应用服务器采用主备模式，主节点处理请求，备节点热备，当主节点故障时，通过心跳检测自动切换。数据库层面，主从复制，主库写操作，从库读操作，主库故障时，从库提升为主库。消息队列用于异步任务，如行李信息处理，避免阻塞主流程。这样，单点故障（如某台服务器、数据库主库）时，系统仍能通过备用组件继续运行，保证服务不中断。
6) 【追问清单】
- 问题1：如何检测服务器故障？回答要点：通过心跳包（如HTTP健康检查）定期检测节点状态，超时则标记为故障。
- 问题2：数据库主从复制如何保证数据一致性？回答要点：主库写操作，从库异步同步，通过二进制日志（binlog）保证数据一致性，故障时从库提升为主库，需考虑同步延迟。
- 问题3：消息队列如何保证消息不丢失？回答要点：消息持久化（写入磁盘），事务机制（生产者发送消息前确保写入磁盘），确保即使服务器故障，消息不会丢失。
- 问题4：如何处理网络分区（脑裂）？回答要点：采用分布式一致性算法（如Raft），选举主节点，避免多个节点同时成为主节点导致数据不一致。
- 问题5：容灾中心如何部署？回答要点：异地部署（如北京与上海），通过专线或云网络连接，实现数据同步与故障切换，确保跨地域故障时系统仍能运行。
7) 【常见坑/雷区】
- 坑1：只说高可用，未具体说明组件（如负载均衡、数据库复制），显得空泛。
- 坑2：只提负载均衡，未提故障检测机制，导致架构不完整。
- 坑3：数据库只说主从，未提读写分离或故障切换流程，无法应对主库故障。
- 坑4：消息队列未考虑异步解耦，导致主流程阻塞，影响用户体验。
- 坑5：未考虑网络故障或脑裂，导致系统在极端情况下崩溃。