设计酒店预订系统的数据库表结构，包括用户表、酒店信息表、房间类型表、订单表等，考虑数据一致性和扩展性，并说明如何处理高并发下的数据一致性（如分布式事务）。

南光集团旅游酒店类难度：中等

答案

1) 【一句话结论】采用分库分表+Saga模式分布式事务方案，核心表设计包含库存表（room_inventory），高并发下通过Saga模式（含库存扣减与补偿）保障数据一致性，允许短暂不一致通过补偿机制恢复。

2) 【原理/概念讲解】首先，数据库设计需遵循第三范式（如用户表、酒店表、房间类型表独立存储，避免冗余）。为实时跟踪房间库存，新增库存表（room_inventory），字段包括room_type_id（关联房间类型表）、available_rooms（剩余可用房间数）、last_update_time（最后更新时间），下单时通过该表快速查询并扣减库存。对于高并发场景，Saga模式是关键：将下单流程拆分为四个独立事务（“查询库存并扣减”→“锁定房间”→“扣减用户余额”→“生成订单”），每个步骤独立提交，失败时通过“补偿事务”回滚（如库存未扣减则释放库存）。高并发下结合最终一致性（允许订单与库存1秒延迟），通过定时任务或消息队列异步补偿，保证数据最终一致。

3) 【对比与适用场景】

两阶段提交：集中式事务管理，协调者与参与者两阶段提交，强一致性但协调者单点故障、性能低，适合小规模系统。
Saga模式：分段事务，每个步骤独立事务，失败时补偿，最终一致性、无协调者、性能高，适合高并发分布式系统（如电商、酒店预订）。

4) 【示例】

表结构：
- users（用户表）：id（UUID）、phone（唯一手机号）、password（加密）、nickname（昵称）、create_time。
- hotels（酒店表）：id（UUID）、name（名称）、address（地址）、city（城市）、create_time。
- room_types（房间类型表）：id（UUID）、hotel_id（外键关联hotels.id）、type_name（房型名称）、price（价格）、capacity（容纳人数）、create_time。
- room_inventory（库存表）：id（UUID）、room_type_id（外键关联room_types.id）、available_rooms（整数，剩余房间数）、last_update_time（时间戳）。
- orders（订单表）：id（UUID）、user_id（外键关联users.id）、hotel_id（外键关联hotels.id）、room_type_id（外键关联room_types.id）、order_time（下单时间）、status（订单状态）、total_price（总价）、create_time。
下单流程Saga步骤：
1. 查询room_inventory，若available_rooms>0则扣减（UPDATE room_inventory SET available_rooms = available_rooms -1 WHERE room_type_id=? AND available_rooms>0）；
2. 更新orders状态为“待支付”；
3. 扣减用户余额；
4. 生成订单。
补偿步骤：若第一步失败（库存扣减失败），补偿释放库存（UPDATE room_inventory SET available_rooms = available_rooms +1 WHERE room_type_id=?）；若第三步失败（扣减余额失败），补偿恢复用户余额。

5) 【面试口播版答案】
“面试官您好，针对酒店预订系统，我设计的数据库表结构包含用户表、酒店表、房间类型表、订单表，以及库存表（room_inventory），用于实时跟踪房间剩余数量。对于高并发场景，采用Saga模式处理分布式事务：下单流程拆分为‘查询库存并扣减’、‘锁定房间’、‘扣减用户余额’、‘生成订单’四个步骤，每个步骤独立事务，失败时通过补偿事务回滚（如库存未扣减则释放库存）。高并发下允许订单与库存有1秒延迟（最终一致性），通过定时任务保证最终一致性。这样既保证了数据一致性，又提升了系统性能。”

6) 【追问清单】

问题1：库存表扣减库存的原子性如何保证？
回答要点：通过数据库事务（如行级锁）保证库存扣减的原子性，避免并发下库存错误。
问题2：Saga模式的补偿失败如何处理？
回答要点：设置重试次数（如3次），失败后记录日志并触发人工干预。
问题3：分库分表的具体策略？
回答要点：按城市分库（如北京、上海分库），按订单ID分表（避免跨库查询）。

7) 【常见坑/雷区】

坑1：忽略库存表导致库存错误，高并发下订单超卖。
坑2：补偿逻辑不完善，补偿失败后数据不一致。
坑3：分库分表设计不合理，如按订单ID分表导致跨库查询，影响性能。
坑4：未考虑扩展性，如未预留字段，未来新增业务（如会员积分）无法快速扩展。
坑5：高并发下未使用最终一致性，导致系统响应慢，用户体验差。