设计一个处理景区门票预订系统的架构，该系统需应对节假日高并发（如国庆期间日订单量百万级），请说明核心组件设计（如订单服务、库存服务、支付网关）、技术选型（数据库、缓存、消息队列）、弹性扩容策略（水平扩展、自动伸缩）以及容灾方案（主从、异地灾备）。

1) 【一句话结论】

采用微服务架构，拆分订单、库存、支付服务，通过Redis缓存（带Lua脚本保证原子性）、Kafka异步解耦、水平扩展+自动伸缩应对高并发，主从+异地灾备保障容灾，核心是“解耦+原子性+弹性+容灾”的分布式设计。

2) 【原理/概念讲解】

系统需拆分为订单服务（处理用户预订、订单状态管理）、库存服务（管理景区票务库存，需高并发读写）、支付网关（对接第三方支付，保障支付安全）。订单服务生成订单后，通过消息队列通知库存服务扣减库存；库存服务用Redis原子操作扣减库存，支付网关处理支付后回调更新订单状态。类比：库存服务像超市库存管理系统，订单服务像收银台，消息队列像快递员，缓存像临时货架，确保收银时库存充足且订单处理高效。

3) 【对比与适用场景】

数据库（MySQL vs MongoDB）

类别	MySQL（关系型）	MongoDB（NoSQL）
定义	结构化数据，支持ACID事务	非结构化/半结构化，高可扩展
特性	事务一致性，强一致性	最终一致性，高吞吐
使用场景	订单表（结构化，需事务）	库存日志（非结构化，日志记录）
注意点	分库分表复杂，事务锁	无事务，数据一致性需业务保证

缓存（Redis vs Memcached）

类别	Redis	Memcached
定义	支持数据结构（字符串、列表等），持久化（RDB/AOF）	简单键值存储，无持久化
特性	高性能，数据结构丰富，事务需Lua脚本	低延迟，无持久化
使用场景	库存扣减（Lua脚本保证原子性），订单状态	热点数据缓存（如景区信息）
注意点	事务需Lua脚本，持久化配置复杂	数据丢失，适合临时缓存

消息队列（Kafka vs RabbitMQ）

类别	Kafka	RabbitMQ
定义	分布式消息系统，高吞吐，持久化	企业级消息队列，保证顺序，持久化
特性	高吞吐，持久化，多消费者	保证消息顺序，支持事务，持久化
使用场景	库存扣减的异步通知（高吞吐）	订单状态同步（需保证顺序）
注意点	需要集群，管理复杂	队列配置复杂，延迟较高

4) 【示例】

用户预订门票流程（伪代码）：

1. 用户请求：

   {
     "userId": "user123",
     "touristSpotId": "spot001",
     "ticketType": "成人票",
     "quantity": 2
   }
   

2. 订单服务：生成订单（订单ID：order_123456），状态为“待支付”，调用库存服务（通过Kafka发送库存扣减消息）。
3. 库存服务：从Redis缓存扣减库存（Lua脚本保证原子性），返回“库存充足”。
4. 支付网关：发起支付请求（返回“待支付”），订单状态更新为“已支付”。
5. 支付回调：支付网关回调订单服务，更新订单状态为“已完成”。

（注：订单服务通过订单ID检查是否重复下单，避免幂等问题。）

5) 【面试口播版答案】

好的，针对景区门票预订系统应对百万级高并发，我的设计是采用微服务架构，拆分为订单、库存、支付等独立服务，核心是通过解耦、原子性操作、弹性扩容和容灾保障。首先，订单服务负责用户预订，库存服务管理票务库存，支付网关对接第三方支付。技术选型上，订单和库存用MySQL分库分表（处理高并发读写），库存扣减用Redis（Lua脚本保证原子性），订单与库存交互通过Kafka异步解耦。弹性扩容采用水平扩展（增加实例），结合自动伸缩（根据CPU负载动态调整），确保系统随负载变化自动扩容。容灾方案上，订单服务主从复制（主写从读，故障时秒级切换），库存服务部署跨城市Redis集群（数据同步到灾备中心，同步频率5分钟一次，切换延迟秒级）。总结来说，通过微服务解耦、Redis原子操作、消息队列异步、弹性扩容和主从+异地灾备，能有效应对高并发，保障系统稳定。

6) 【追问清单】

• 问：库存扣减时如何保证原子性？
  答：使用Redis Lua脚本执行原子操作，确保库存扣减和订单创建同时完成，避免超卖。
• 问：消息队列积压时如何处理？
  答：设置消息队列的消费者数量和批量消费，结合限流策略，避免系统过载，同时配置死信队列处理无法重试的消息。
• 问：容灾方案中异地灾备的数据同步延迟如何？
  答：通过异步复制（如每5分钟同步一次），切换延迟控制在秒级内，不影响业务。
• 问：订单服务如何处理幂等性？
  答：通过订单ID作为唯一标识，检查订单是否已存在，若存在则直接返回，避免重复下单。
• 问：缓存与数据库的同步机制？
  答：设置Redis缓存TTL（如5分钟），并定期更新缓存数据，确保数据一致性。

7) 【常见坑/雷区】

• 强耦合：订单服务直接调用库存服务，导致库存服务压力过大，应通过消息队列解耦。
• 缓存未失效：未设置TTL，可能导致缓存数据过期后，订单服务获取过时库存，引发超卖。
• 消息队列无死信：积压消息未处理，导致订单积压，应配置死信队列和重试机制。
• 容灾仅主从：未考虑异地灾备，主节点故障时，异地节点无法及时接管，导致数据丢失。
• 数据库未分库分表：高并发时数据库连接数达到上限，服务崩溃，应提前分库分表，并考虑读写分离。