网上购电影票系统面试题：从入门到精通的5个核心考点

官方文档太长抓不住重点？别慌。很多应届生做网上购电影票项目，看了一天文档还是懵的，根本分不清哪段代码是核心，哪句注释是废话。今天不熬鸡汤，直接拆解这个经典场景在面试中的高频陷阱。网上购电影票看似简单，实则涵盖了并发控制、数据一致性、状态机等后端核心难点。想要从入门到精通，必须把这些底层逻辑吃透，而不是只会调API。

考点梳理：别把业务当玩具

很多同学在简历上写“实现网上购电影票功能”，面试官一听就皱眉。为什么？因为购票系统最核心的矛盾是超卖和状态一致性。如果不懂这两点，你的系统就是玩具。

面试中常见的错误认知有三个。第一，认为只要加个if判断库存大于0就行。这在单线程下没问题，高并发下直接崩溃。第二，认为数据库事务能解决所有问题。事务只能保证原子性，不能解决性能瓶颈，锁表会导致请求堆积。第三，忽略支付回调的幂等性。用户支付后网络抖动，回调发两次，你的系统扣两次票还是退一次款？

核心考点清单：

高并发下的库存扣减：如何防止超卖？
分布式锁的应用：Redis锁还是数据库锁？
状态机设计：订单状态如何流转？
幂等性设计：如何防止重复支付？
数据一致性：最终一致性方案。

面试官问网上购电影票，本质是在问分布式系统基础。你答的是业务，他听的是架构能力。

标准答法：结构化输出逻辑

回答这类问题，切忌东一榔头西一棒子。建议采用**“现状-方案-兜底”**三段式。

第一步：描述场景与痛点。 “网上购电影票系统面临高并发秒杀场景，主要痛点是库存超卖和订单状态不一致。传统数据库行锁在高并发下性能急剧下降，无法满足峰值流量。”

第二步：给出核心解决方案。 “我采用了Redis预扣减库存 + 数据库异步落库的方案。

预扣减：将库存预热到Redis，利用Lua脚本原子性执行decr和判断，快速拦截无效请求。
异步落库：Redis扣减成功后，发送消息到MQ，消费者异步调用数据库接口创建订单并扣减DB库存。
补偿机制：如果数据库扣减失败，发送重试消息，并回滚Redis库存。”

第三步：补充兜底策略。 “为了应对Redis宕机或MQ丢失，我设计了定时对账任务。每小时比对Redis库存与DB库存，差异超过阈值则告警并人工介入。同时，支付回调接口通过唯一订单号保证幂等性，避免重复退款。”

加分项：提及官方源码仓库。 可以提到：“在实现Redis Lua脚本时，我参考了Redis官方源码仓库中t_clue.c关于原子操作的实现逻辑，确保脚本在执行过程中不会被中断，保证了原子性。”这句话能体现你不仅会用，还懂底层。

代码实现：Lua脚本与幂等设计

光说不练假把式。这里给出最核心的Redis Lua脚本和Java幂等处理代码。这是面试必考代码。

1. Redis Lua脚本：原子扣减库存

为什么用Lua？因为Redis执行Lua脚本时是单线程的，整个脚本执行期间不会被其他命令插入，天然具备原子性。

-- 文件: deduct_stock.lua
-- 参数: KEYS[1] = 电影场次库存key, ARGV[1] = 购买数量
local stock_key = KEYS[1]
local buy_count = tonumber(ARGV[1])-- 1. 检查库存是否存在
if redis.call('exists', stock_key) == 0 thenreturn -1 -- 库存key不存在，返回-1
end-- 2. 获取当前库存
local current_stock = tonumber(redis.call('get', stock_key))-- 3. 判断库存是否充足
if current_stock < buy_count thenreturn 0 -- 库存不足，返回0
end-- 4. 扣减库存
redis.call('decrby', stock_key, buy_count)-- 5. 返回扣减后的剩余库存
return current_stock - buy_count

代码解析：

原子性：exists、get、decrby在一个脚本内执行，中间不会插入其他线程操作，彻底解决check-then-act竞态条件。
返回值设计：返回剩余库存，方便后续逻辑判断。返回-1表示key异常，0表示库存不足，正数表示成功。

2. Java端：幂等性处理

支付回调是最容易出Bug的地方。用户支付成功，微信/支付宝回调通知。如果网络超时，对方会重试。你的接口必须能处理重复请求。

@Service
public class OrderService {@Autowiredprivate RedisTemplate<String, String> redisTemplate;@Autowiredprivate OrderMapper orderMapper;@Autowiredprivate TransactionTemplate transactionTemplate;/*** 处理支付回调* @param orderNo 订单号* @param payAmount 支付金额* @return 处理结果*/public boolean handlePayCallback(String orderNo, BigDecimal payAmount) {// 1. 幂等性检查：使用Redis SETNX，有效期1天String idempotentKey = "pay:callback:" + orderNo;Boolean isProcessed = redisTemplate.opsForValue().setIfAbsent(idempotentKey, "1", 1, TimeUnit.DAYS);if (Boolean.FALSE.equals(isProcessed)) {// 已经处理过，直接返回成功，防止重复退款log.warn("订单 {} 支付回调重复，忽略处理", orderNo);return true;}// 2. 业务处理：开启事务return transactionTemplate.execute(status -> {try {// 查询订单，加锁Order order = orderMapper.selectForUpdate(orderNo);if (order == null) {throw new BusinessException("订单不存在");}// 校验状态：只有待支付状态才能转已支付if (order.getStatus() != OrderStatus.PENDING_PAY) {throw new BusinessException("订单状态错误");}// 校验金额if (order.getAmount().compareTo(payAmount) != 0) {throw new BusinessException("支付金额不一致");}// 更新订单状态为已支付order.setStatus(OrderStatus.PAID);order.setPayTime(new Date());orderMapper.update(order);// 扣减数据库真实库存（如果Redis是预扣减，这里做最终一致性校验或扣减）// 注意：实际生产中，DB库存扣减应在创建订单时做，或者通过MQ异步做// 这里假设是最终扣减boolean stockDeducted = cinemaMapper.deductStock(order.getCinemaId(), order.getSeatCount());if (!stockDeducted) {throw new BusinessException("库存扣减失败");}return true;} catch (Exception e) {// 3. 异常处理：删除幂等键，允许重试redisTemplate.delete(idempotentKey);status.setRollbackOnly();throw e;}});}
}

代码解析：

SETNX幂等：利用Redis的SETNX（Set If Not Exist）特性。第一次请求成功设置，后续重复请求返回false，直接跳过业务逻辑。
事务回滚与幂等键清除：如果业务处理失败（如DB扣库存失败），必须删除Redis中的幂等键。否则，后续重试也会因为键存在而被拦截，导致数据不一致。
悲观锁：selectForUpdate对订单行加锁，防止并发修改同一订单。

追问与延伸：进阶技巧与避坑

面试官不会只问基础。以下是三个高频追问，答不好直接挂。

追问1：Redis挂了怎么办？

错误回答：“重启Redis，数据丢了就丢了，从DB同步。” 正确思路：

持久化：开启RDB+AOF混合持久化，确保宕机重启后数据尽量恢复。
降级策略：如果Redis集群不可用，网关层直接拒绝新请求，返回“系统繁忙”，保护DB不被打垮。
数据修正：恢复后，运行对账脚本，以DB库存为准，修正Redis库存。

追问2：如果MQ消息丢失呢？

错误回答：“MQ不可能丢消息。” 正确思路：

生产端：使用同步发送+重试机制，或者事务消息（RocketMQ）。
消费端：手动ACK，处理成功后再确认。失败则重试，超过最大重试次数进入死信队列。
死信处理：人工介入或定时任务扫描死信队列，补偿执行。

追问3：为什么不用数据库乐观锁？

对比分析：

乐观锁：update set stock = stock - 1 where id = ? and stock > 0。
- 优点：无锁，实现简单。
- 缺点：高并发下失败率高，大量请求重试，DB压力大。
Redis+Lua：
- 优点：内存操作，速度极快，能扛住高并发。
- 缺点：需要处理Redis与DB的一致性，架构复杂度略高。

结论：秒杀场景（如电影票开售瞬间），流量极大，必须用Redis削峰。普通场景（如日常购票），DB乐观锁足够，无需过度设计。

记忆口诀：快速回顾核心

为了面试前快速回忆，记住这个口诀：“一预二异三对账，幂等锁表别忘详”。

一预：Redis预扣减库存，拦截无效流量。
二异：异步MQ落库，解耦高并发。
三对账：定时任务比对Redis与DB，兜底数据一致性。
幂等：支付回调用SETNX，防重复。
锁表：DB更新加悲观锁，防并发冲突。
别忘详：异常回滚要删幂等键，细节决定成败。

晋升与职业发展路径思考： 网上购电影票项目虽然经典，但只是入门。在简历中，不要只写“实现了购票功能”。要写“设计了高并发下的库存扣减方案，通过Redis Lua脚本将QPS从1k提升到50k，并引入MQ异步落库，系统可用性达到99.99%”。对于应届生，这个项目是敲门砖。对于1-3年工程师，要能讲清楚为什么这么选，而不是怎么实现。面试官考察的是你的技术选型能力和权衡（Trade-off）能力。关于证书变更与注销流程、证书补办流程，这属于行政或特定行业（如PMP、软考）范畴，与技术面试无直接关联。但在工程类面试中，“流程思维”很重要。比如，你如何设计订单取消流程？如何设计退款流程？这些流程的状态机设计，才是面试官想看的。确保你的系统状态流转清晰：待支付 -> 已支付 -> 已出票 -> 已退票，每个状态变更都有明确的前置条件和后置操作。

网上购电影票系统看似简单，实则涵盖了分布式系统的核心难题。从入门到精通，关键在于理解并发和保证一致性。不要为了用技术而用技术，要基于业务场景做合理选型。

还有什么不懂的?评论区留言挨个回。