设计一个高并发的酒店预订系统，需支持大促期间每秒数千笔订单处理，请描述系统的架构设计（包括前端、后端、数据库、缓存、消息队列等组件的选择与职责划分），并说明如何保证系统的高可用性和低延迟。
南光集团旅游酒店类难度：中等
答案
1) 【一句话结论】
采用微服务拆分业务，结合分布式缓存（Redis）、消息队列（Kafka）和数据库分库分表，通过负载均衡、读写分离等手段，实现高并发下的低延迟和高可用性，核心是解耦、分库分表、缓存穿透/雪崩处理。
2) 【原理/概念讲解】
老师口吻解释各组件作用：
- 微服务：将系统拆分为预订、库存、支付等独立服务，每个服务独立部署，提高扩展性。类比：大公司分部门，各部门专注业务，协同高效。
- 负载均衡：用Nginx/LVS分发请求到多台后端服务器，避免单点故障，提升吞吐量。类比：餐厅多收银员，减少排队。
- 缓存（Redis）：存储热门酒店信息、订单状态，减少数据库压力。类比：超市货架，畅销商品快速取用，减少去仓库的时间。
- 消息队列（Kafka）：解耦订单处理流程（如下单后异步扣减库存、通知支付），避免阻塞主流程。类比：快递分拣中心，订单分拣后由快递员配送，提高效率。
- 数据库分库分表：订单表按酒店ID分库分表，避免单表数据过大。类比：图书馆书架，不同类型书放不同书架，方便查找。
- 读写分离：主库写，从库读，提升读性能。类比：银行主账户存钱，副账户查余额，减少主账户压力。
3) 【对比与适用场景】
| 策略/组件 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| 缓存穿透 | 请求不存在的数据，缓存未命中且数据库无结果 | 可能导致缓存和数据库压力激增 | 热门数据查询 | 需布隆过滤器或缓存空值 |
| 缓存雪崩 | 大量缓存同时过期，请求直接访问数据库 | 瞬间流量激增，数据库崩溃 | 缓存统一过期时间 | 设置随机过期时间或热点数据永不过期 |
| 消息队列（Kafka） | 分布式消息系统，高吞吐、持久化 | 实时性高，水平扩展 | 订单处理、日志收集 | 需考虑消息积压 |
| 消息队列（RabbitMQ） | 企业级消息中间件，支持多种消息模型 | 可靠性高，延迟低 | 事务消息、订单确认 | 需手动确认消息 |
4) 【示例】
请求流程（用户预订酒店）：
- 前端请求后，后端查询Redis缓存（
hotel_info:hotel_id），存在则直接返回。 - 缓存未命中，查询数据库（分库分表，如订单表按酒店ID分表），获取酒店信息。
- 调用库存微服务，检查库存（库存扣减通过消息队列异步处理）。
- 下单后，订单服务写入数据库，并调用支付服务（异步，通过消息队列通知）。
- 支付成功后，消息队列更新订单状态，最终返回成功信息。
伪代码（后端）：
def book_hotel(hotel_id, room_count, date):
hotel = redis.get(f"hotel_info:{hotel_id}")
if hotel: return parse_hotel(hotel)
hotel = db.query("SELECT * FROM hotels WHERE id = ?", hotel_id)
if not hotel: return {"error": "酒店不存在"}
stock = stock_service.check_stock(hotel_id, room_count, date)
if stock < room_count: return {"error": "库存不足"}
stock_service.deduct_stock(hotel_id, room_count, date) # 异步扣减
order_id = db.insert("INSERT INTO orders (hotel_id, room_count, date, status) VALUES (?, ?, ?, ?)", hotel_id, room_count, date, "待支付")
kafka_producer.send("payment_notifications", {"order_id": order_id, "hotel_id": hotel_id})
return {"order_id": order_id, "message": "预订成功，请支付"}
5) 【面试口播版答案】
面试官您好，设计高并发酒店预订系统，核心是采用微服务拆分业务，结合分布式缓存、消息队列和数据库分库分表。具体来说，前端通过负载均衡分发请求，后端服务拆分为预订、库存、支付等微服务。缓存用Redis存储热门酒店信息，减少数据库压力；消息队列用Kafka解耦订单处理流程，比如下单后异步扣减库存、通知支付。数据库方面，订单表按酒店ID分库分表，读写分离，主库写，从库读。高可用方面，各组件部署多实例，通过健康检查实现自动切换，缓存设置随机过期时间避免雪崩，消息队列设置消费限流防止积压。这样能支持大促期间每秒数千笔订单，保证低延迟和高可用。
6) 【追问清单】
- 问：如何处理缓存穿透？
答：使用布隆过滤器提前过滤不存在的数据，或缓存空值（设置过期时间但数据为空）。 - 问：订单库存一致性问题如何保证？
答：通过消息队列异步扣减库存，确保库存扣减和订单创建顺序，避免强一致性要求下的阻塞。 - 问：消息队列积压时如何处理？
答：增加消费者实例或设置消息重试机制，避免积压导致延迟。 - 问：数据库分库分表后，如何保证跨表查询？
答：尽量按业务拆分表，避免跨库查询，或使用数据库中间件（如MyCat）统一管理。
7) 【常见坑/雷区】
- 只说缓存，未考虑缓存穿透/雪崩的解决方案，导致系统崩溃。
- 消息队列选错（如用RabbitMQ但场景需高吞吐），导致性能瓶颈。
- 数据库未分库分表，单表数据过大，查询/写入性能下降。
- 高可用只说主从，未考虑多活（主从切换时间长），或网络分区时数据不一致。
- 延迟优化不足，缓存未命中时数据库查询时间过长，用户等待时间增加。