铁路调度系统需处理高并发票务请求（类似12306），请设计分布式架构，包括负载均衡、缓存策略、消息队列设计，并讨论如何保证系统高可用和低延迟。
答案
1) 【一句话结论】
铁路调度系统高并发场景下，采用微服务+分布式架构，通过负载均衡分散请求、多级缓存（含缓存穿透/雪崩应对）降低数据库压力、消息队列解耦异步流程，结合多机房部署、数据库读写分离等保障高可用与低延迟，旨在应对百万级请求下的低延迟和高可用。
2) 【原理/概念讲解】
面试官您好，我们来拆解核心组件的原理。首先是负载均衡，它像交通枢纽的调度站，把海量用户请求分散到不同服务器，避免单点过载。常见方案有LVS（四层负载，高性能，适合大规模）和Nginx（七层负载，支持HTTP智能路由，如会话保持）。其次是多级缓存，缓存的核心是“把热门数据放在快速访问层”，比如铁路系统中，热门线路余票属于高频访问数据。我们采用本地缓存（如内存Map）+ Redis分布式缓存：服务实例先查本地缓存，未命中再查Redis，最后查数据库，大幅降低数据库压力。针对缓存穿透（大量请求查询不存在的数据，导致数据库压力激增），用布隆过滤器+空对象缓存（布隆过滤器判断数据是否存在，若不存在则缓存空对象，避免空查询）；针对缓存雪崩（大量缓存同时过期，导致数据库瞬间过载），用随机过期时间+热备节点（缓存数据设置随机过期时间，避免集中过期，同时部署热备节点，主节点故障时快速切换）。然后是消息队列，它像快递中转站，把购票请求先存入队列，再由购票服务消费，避免高并发时服务直接崩溃，保证请求不丢失。消息队列采用Kafka，持久化存储（日志存储）确保消息不丢失，事务消息保障发送和消费的原子性（如RocketMQ的事务消息）。最后是高可用与低延迟，高可用通过多机房部署（主备切换，数据同步用数据库复制或消息队列同步）、数据库读写分离（读请求分散到多个数据库实例）实现；低延迟通过缓存预热（定时任务或动态预热策略，提前加载热门数据到缓存）、负载均衡的会话保持（保持用户会话一致性）、消息队列的批量处理（减少单次请求延迟）实现。
3) 【对比与适用场景】
以负载均衡方案为例，对比LVS和Nginx的特点：
| 方式 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| LVS | Linux虚拟服务器，基于IP负载均衡 | 高性能，支持四层/七层负载，无状态转发 | 大规模高并发场景（如铁路系统百万级请求），对性能要求极高 | 需要Linux内核支持，配置复杂，依赖操作系统 |
| Nginx | 高性能HTTP服务器，可作反向代理 | 七层负载均衡，支持会话保持、请求路由等智能策略 | Web应用（如铁路票务系统），尤其是HTTP请求为主 | 配置灵活，但七层处理可能引入额外延迟 |
4) 【示例】
以缓存穿透解决方案为例，假设用户查询“北京-广州”车票（实际无此线路），流程如下：
- 用户请求到达服务，先查本地缓存（无）；
- 再查Redis（无）；
- 布隆过滤器判断该线路不存在（布隆过滤器配置正确，判断为不存在）；
- 此时缓存空对象（如缓存“北京-广州：0”），并返回给用户，避免后续请求再次查询数据库；
- 数据库中无此线路数据，所以不会影响。
5) 【面试口播版答案】
面试官您好，针对铁路调度系统高并发场景，我设计的分布式架构核心是“分散请求-缓存热点数据-异步解耦流程-多级保障高可用”。首先，负载均衡，用Nginx做七层负载均衡，根据请求类型（如查询/购票）和服务器负载动态分发，避免单点过载；然后，缓存策略，采用本地缓存+Redis分布式缓存，热门车票信息放在Redis，查询请求先查Redis，未命中再查数据库，减少数据库压力；针对缓存穿透，用布隆过滤器+空对象缓存（布隆过滤器判断数据是否存在，若不存在则缓存空对象，避免空查询）；针对缓存雪崩，用随机过期时间+热备节点（缓存数据设置随机过期时间，避免集中过期，同时部署热备节点，主节点故障时快速切换）。接着，消息队列，用Kafka处理购票请求的异步流程，用户购票请求先进入Kafka（持久化存储），由购票服务消费并处理，避免高并发时服务直接崩溃；高可用方面，多机房部署（主备切换，数据同步用数据库复制），数据库读写分离（读请求分散到多个数据库实例）；低延迟方面，缓存预热（定时任务提前加载热门数据到缓存），负载均衡的会话保持（保持用户会话一致性），消息队列的批量处理（减少单次请求延迟）。这样整体架构既能应对百万级高并发，又能保证系统高可用和低延迟。
6) 【追问清单】
- 数据一致性如何保障？
回答要点：用分布式事务（如两阶段提交，适用于强一致性场景，如库存扣减和订单生成）或最终一致性（如消息队列+补偿机制，适用于弱一致性场景，如铁路票务系统，库存扣减后通过消息通知其他服务更新）。 - 消息队列如何保证消息不丢失？
回答要点：用持久化存储（如Kafka的日志存储），确保消息写入磁盘；结合事务消息（如RocketMQ的事务消息），保障消息发送和消费的原子性。 - 缓存预热的具体实现方式？
回答要点：定时任务（如凌晨0点）或动态预热策略（如根据实时访问热点数据，动态加载到缓存），提前加载热门数据到缓存，减少首次查询延迟。
7) 【常见坑/雷区】
- 忽略数据一致性保障：未提及分布式事务或最终一致性，导致业务数据不一致（如库存扣减后订单未生成）。
- 绝对化表述：如“确保系统在百万级请求下仍能保持低延迟和高可用”，应改为“旨在应对百万级请求下的低延迟和高可用”。
- 缓存预热未说明具体方式：未提及定时任务或动态预热策略，导致缓存预热方案不具体。
- 消息队列未考虑持久化与事务：未说明Kafka的日志存储或事务消息，导致消息丢失风险。
- 高可用设计未考虑多机房同步：未提及数据库复制或消息队列同步，导致跨机房数据不一致或延迟过高。