1嗨租车系统重构：搞定高频面试题，拒绝只会背八股

看了一堆教程还是不会写项目？别急着焦虑，这恰恰是你离高频面试题最近的时候。很多人卡在“看懂了但写不出”的泥潭里，根源不是语法不熟，而是缺乏从业务场景到代码落地的思维闭环。今天我们就以“1嗨租车”这个典型的中台业务为例，拆解那些让你头秃的并发、状态机与数据一致性问题。这不只是一篇教程，更是你面试前的最后一道防线。

考点梳理：业务背后的技术陷阱

“1嗨租车”看似简单的下单流程，实则包含了分布式系统中三大难题：库存超卖、状态流转混乱、支付回调丢失。

在传统的单体应用中，我们可能只用一个 if-else 就能搞定。但在高并发场景下，比如节假日租车高峰，成千上万个请求同时抢占同一辆热门车型，这时候你的系统会怎样？

核心痛点分析：

库存扣减竞争：两个用户同时看到剩1辆车，都点击支付，最后库存变成-1，或者两人都支付成功但只有一辆车。
订单状态不可逆：用户取消订单后，库存未回滚；或者支付超时，订单状态卡在“待支付”，导致车辆无法被再次出租。
第三方依赖不稳定：支付网关响应慢或失败，本地订单状态与支付状态不一致。

这些问题在面试中几乎必问。面试官不会只问你“怎么加锁”，他会问你：“如果Redis挂了，你的库存怎么保证不超卖？”或者“支付回调重复到达，你的订单状态会乱吗？”

标准答法：构建高可用的状态机模型

回答这类问题，切忌直接甩代码。先讲思路，再讲方案。

第一步：引入状态机（State Machine） 订单不是简单的“创建-支付-完成”，而是一个严格的状态流转图。

INIT (初始化) -> PAID (已支付) -> RENTED (已取车) -> RETURNED (已还车) -> CLOSED (已关闭)
每个状态转换必须有明确的触发条件（Trigger）和前置校验（Guard）。

第二步：解决并发库存问题 不要直接在数据库里 UPDATE stock = stock - 1。

推荐方案：Redis Lua 脚本原子操作。
理由：Lua 脚本在 Redis 中是原子执行的，天然避免并发竞争。即使 Redis 宕机，也可通过消息队列（MQ）补偿机制，从数据库重新加载库存快照。

第三步：幂等性设计 支付回调可能重复。必须引入 unique_token（如订单号+支付流水号）作为幂等键。

在 Redis 中 SETNX 该 Token，过期时间设为24小时。
如果 Key 存在，直接返回成功，不再处理业务逻辑。

面试话术参考： “在处理1嗨租车的订单状态时，我采用了有限状态机模式。针对高并发下的库存超卖问题，我利用 Redis Lua 脚本实现原子扣减，避免了传统数据库锁的性能瓶颈。同时，为了应对支付回调的不确定性，我引入了基于 Redis 的幂等性校验，确保同一笔支付只触发一次订单状态变更。”

代码实现：Redis Lua 原子扣减与状态流转

下面是一段核心代码，展示了如何在高并发下安全地扣减库存并创建订单。

import redis
import uuid
from datetime import datetime# 连接Redis
r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)# Lua脚本：原子性检查并扣减库存
# KEYS[1]: 库存Key, e.g., "stock:car:bmw_x5:001"
# ARGV[1]: 扣减数量, e.g., "1"
lua_script = """
local stock = redis.call('GET', KEYS[1])
if stock == false thenreturn -1  -- 库存Key不存在
end
local stock_num = tonumber(stock)
if stock_num < tonumber(ARGV[1]) thenreturn 0   -- 库存不足
end
redis.call('DECRBY', KEYS[1], ARGV[1])
return 1       -- 扣减成功
"""# 注册脚本
deduct_stock_script = r.register_script(lua_script)def create_rental_order(car_id, user_id):"""模拟1嗨租车下单流程"""order_id = f"ORD{uuid.uuid4().hex[:16]}"stock_key = f"stock:car:{car_id}"# 1. 尝试原子扣减库存result = deduct_stock_script(keys=[stock_key], args=[1])if result == -1:raise Exception("车辆库存初始化失败，请联系管理员")elif result == 0:return {"status": "FAILED", "reason": "车辆已被抢光"}# 2. 库存扣减成功，执行本地业务逻辑# 在实际生产中，这里应该发送MQ消息，由消费者创建数据库订单# 这里简化为直接写入数据库逻辑示意try:# 模拟数据库操作# db.insert_order(order_id, user_id, car_id, status='INIT')print(f"[SUCCESS] 订单 {order_id} 创建成功，车辆 {car_id} 库存已预占")# 3. 设置超时自动释放库存（假设30分钟未支付则释放）# 实际中可以使用 Redis 的 EXPIRE 或延时队列r.expire(stock_key, 0) # 示例：仅演示，实际需自定义释放逻辑return {"status": "SUCCESS", "order_id": order_id}except Exception as e:# 4. 异常补偿：回滚库存r.incrby(stock_key, 1)print(f"[ROLLBACK] 订单创建失败，已回滚库存: {str(e)}")raise# 测试高并发场景
import threadingdef simulate_user():try:result = create_rental_order("BMW_X5_001", "user_123")if result["status"] == "SUCCESS":print(f"用户抢单成功: {result['order_id']}")except Exception as e:pass# 模拟100个并发请求
threads = []
for i in range(100):t = threading.Thread(target=simulate_user)threads.append(t)t.start()for t in threads:t.join()

代码解析：

Lua 脚本原子性：GET 和 DECRBY 在 Redis 中是一次执行，中间不会插入其他客户端的操作，彻底杜绝了“查完再扣”的时间差漏洞。
异常回滚：如果数据库写入失败（如网络抖动），必须执行 incrby 回滚库存。这是很多新手容易忽略的“脏数据”源头。
超时释放：真实场景中，需结合延时队列（如 RabbitMQ Delayed Plugin 或 RocketMQ 定时消息）处理未支付订单的自动取消与库存释放。

追问与延伸：面试官的“杀手锏”

当你讲完上述方案，面试官通常会抛出更深层的问题。

追问1：如果 Redis 主从切换导致数据丢失怎么办？

回答：Redis 只是库存的缓存层，数据库才是数据源。在业务低峰期（如凌晨2点），通过定时任务将数据库中的真实库存同步到 Redis。如果 Redis 数据丢失，服务会降级为直接查库扣减，虽然性能下降，但保证数据一致性。这是典型的“最终一致性”策略。

追问2：状态机如何防止非法跳转？

回答：在代码层面，使用枚举类定义状态，并通过映射表（Map）定义合法的前驱状态。

// Java 示例
private static final Map<OrderStatus, Set<OrderStatus>> VALID_TRANSITIONS = new HashMap<>();
static {VALID_TRANSITIONS.put(OrderStatus.INIT, Set.of(OrderStatus.PAID, OrderStatus.CLOSED));VALID_TRANSITIONS.put(OrderStatus.PAID, Set.of(OrderStatus.RENTED, OrderStatus.CANCELLED));// ...
}
public void changeStatus(OrderStatus current, OrderStatus next) {if (!VALID_TRANSITIONS.get(current).contains(next)) {throw new IllegalStateTransitionException();}
}

这种设计让状态流转变得可配置、可审计。

追问3：如何监控“僵尸订单”？

回答：搭建 Prometheus + Grafana 监控体系。关键指标包括：order_create_duration（下单耗时）、inventory_sync_lag（库存同步延迟）、zombie_order_count（超过30分钟未支付且未释放的订单数）。当 zombie_order_count 超过阈值时，触发报警并自动执行清理脚本。

避坑指南：

不要相信“软删除”：在租车业务中，车辆是物理资源，删除记录会导致资产盘点混乱。务必使用状态字段标记。
日志要带 TraceID：1嗨租车涉及支付、车辆、用户多个微服务。没有全链路 TraceID，排查问题就像在迷宫里找针。参考 Stack Overflow 上关于分布式追踪的热门讨论，OpenTelemetry 是目前业界的最佳实践。