从电商秒杀到赛事抢票：高并发选座系统设计与锁座机制全解析

一张赛事门票背后的系统难题：为什么抢票系统不能照搬电商秒杀

很多开发者第一次接触赛事票务系统，第一反应都是“不就是个秒杀吗？改改库存不就行了”。我做这套基于SpringBoot的赛事门票预订与座位选择系统之前，也是这么想的，结果真正动手才发现，票务系统的难度和电商秒杀完全不在一个量级。

先看业务场景：某场热门赛事开票，2万张座位，开票头一分钟内可能有几万个请求同时涌进来。用户不是“抢到一个商品”，而是必须先选一个具体座位，锁住它，然后付款。座位不能重叠卖，订单状态要可靠流转，支付超时要自动释放座位，入场还要做核验。任何一个环节出问题，轻则用户体验崩坏，重则造成批量超卖、资金和票务不一致，这是我们做技术方案时最不敢马虎的地方。

这篇文章就围绕这套系统的设计与实现展开，核心是讲清楚四件事：票务系统的业务链路和数据模型怎么搭、可视化选座前后端怎么做、高并发下座位锁和库存扣减怎么保证不超卖、订单状态机和支付超时回收怎么保证一致性。适合正在做或准备做票务、预约、选座类系统的开发同学参考，也适合想了解一下高并发场景下架构设计思路的后端工程师。

1. 一张赛事门票背后的系统难题：为什么抢票系统不能照搬电商秒杀

1.1 票务系统和电商秒杀的三点本质差异

电商秒杀和赛事抢票表面看都是“高并发 + 限量库存”，但底层逻辑差别非常大。我把它们拆成三点，这三点直接决定了系统设计的方向。

第一，库存维度不同。电商商品的库存是一个数字，比如某款手机库存1000台，所有请求抢的都是同一个抽象数字；票务系统的库存是离散座位，2万个座位就是2万行数据，每个座位ID独立存在。用户选A区3排5号和选B区10排2号，完全是两个不同的“商品对象”。这导致我们不能用单一的Redis计数器来做库存扣减，否则无法表达“具体哪个座位被占”。

第二，失败策略不同。电商秒杀抢不到就返回失败，用户换个商品继续抢；票务系统里用户选中心位置，如果锁座失败，大概率是因为座位被别人占了，用户会换相邻的位置再试一次。这意味着同一场次、同一区域甚至同一排，会有大量的重复请求打到相同的热点座位上，热点冲突比电商秒杀更集中。

第三，链路长度不同。电商秒杀通常是“扣库存 → 生成订单”，链路短，失败立即回滚；票务系统是“选座 → 锁座 → 创建未支付订单 → 支付 → 出票 → 入场”，锁座和支付之间有一个长达十几分钟的超时窗口。在这个窗口内，座位不能被别人买到，但不能永远锁死，必须有一套可靠的超时释放机制。这一条是很多从电商转来做票务的团队最容易栽跟头的地方——漏了超时回收，库存很快就被占满，整场票卖不出去。

1.2 技术选型与整体架构思路

这个项目我采用了模块化单体的架构：SpringBoot负责核心业务接口，MySQL存业务数据，Redis做缓存和分布式锁，消息队列做支付超时延迟任务和异步通知，前端用Vue框架配合Canvas来做座位图渲染。

为什么不用微服务？票务系统的业务边界其实很清晰，用户、场次、订单、支付、票务可以拆成五个服务，但拆开的代价是跨服务事务。座位锁定这个动作既涉及座位状态更新，又涉及订单创建，拆成两个服务后就需要分布式事务，复杂度一下子高了很多。对于2万人规模的票务系统，模块化单体完全扛得住，而且开发调试效率高得多。等业务量真的上来，再按订单、票务等模块垂直拆分也不迟，模块化单体在代码层面保留了清晰的边界，拆起来不费劲。

2. 从开票到入场：完整业务链路与核心数据模型设计

2.1 业务主流程拆解

整个系统的主流程分八个环节：场次发布、座位快照生成、开票预告、用户浏览选座、锁座、创建订单、支付出票、入场核验。其中“座位快照生成”是票务系统特有的一步，这也是给后续所有并发控制打基础的关键动作。

在每个场次开票前，后台会基于基础座位布局一次性生成该场次的所有可售座位数据。为什么不能实时查布局表再算库存？因为座位的状态在开票后是动态变化的：被锁、被售、被释放、被禁用。如果每次查库存都要去布局表里做计算，就无法承受高并发下的状态叠加。提前把快照生成好，开票期间所有座位状态的变更都只操作这一份数据，逻辑清晰，锁粒度也细。

2.2 核心表结构：座位与订单怎么建模

先看场次座位表的设计：

CREATE TABLE show_seat ( id BIGINT PRIMARY KEY AUTO_INCREMENT, session_id BIGINT NOT NULL COMMENT '场次ID', area_id BIGINT NOT NULL COMMENT '区域ID', row_no SMALLINT NOT NULL COMMENT '排号', seat_no SMALLINT NOT NULL COMMENT '座位号', coord_x INT NOT NULL COMMENT '画布x坐标', coord_y INT NOT NULL COMMENT '画布y坐标', status TINYINT NOT NULL DEFAULT 1 COMMENT '1=可售 2=锁定 3=已售 4=预留 5=禁用', version INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', order_id BIGINT DEFAULT NULL COMMENT '占用订单ID', locked_expire_time DATETIME DEFAULT NULL COMMENT '锁座到期时间', UNIQUE KEY uk_session_seat (session_id, row_no, seat_no), KEY idx_session_status (session_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单表和订单明细表：

CREATE TABLE order_info ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(40) NOT NULL COMMENT '订单号', user_id BIGINT NOT NULL, session_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0=待支付 1=支付中 2=已支付 3=已出票 4=已取消 5=已退款', expire_time DATETIME NOT NULL COMMENT '支付截止时间', pay_time DATETIME DEFAULT NULL, UNIQUE KEY uk_order_no (order_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, seat_id BIGINT NOT NULL, seat_price DECIMAL(10,2) NOT NULL, UNIQUE KEY uk_order_seat (order_id, seat_id), UNIQUE KEY uk_seat_order (seat_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里有两个容易被忽略但至关重要的唯一约束。第一个是uk_seat_order，一个座位只能出现在一个订单的明细里，这是从数据库层面兜底防止同一座位被重复下单。第二个是order_no的唯一索引，保证支付回调处理时不会因为并发或重复消息产生多笔订单。

2.3 为什么要把每个座位当作独立“库存原子”

很多设计会把库存抽象为“场次总库存”这种数字字段，这样做的问题在于无法精确表达座位占用情况。比如区域库存剩500，但用户看到的座位图里只有东侧的几个位置是空的，这时候光凭数字无法判断用户选的座位是否真的可售。

所以我的做法是：库存的最小单位就是座位。每个座位一行记录，状态字段控制它处于什么生命周期。锁座时执行UPDATE show_seat SET status=2 WHERE id=? AND status=1，这条SQL自带条件判断，在数据库层面就保证了同一个座位不可能被两个人同时从“可售”改到“锁定”——这是整个系统不超卖的最底层保障，也是把座位当成独立原子最直接的好处。后面讲并发控制时，所有方案都是围绕这一行的状态变更来设计的。

3. 可视化选座的关键：座位坐标模型、渲染方式与前后端交互协议

3.1 座位坐标模型与前端渲染选型

选座页是用户感知最强的界面，也是技术上比较容易翻车的地方。上万人的场馆，座位图一加载就是一整片坐标点，前端渲染方式的选择直接影响流畅度。

座位图的数据结构按区域分组。一个场馆划分为A区、B区、C区等若干区域，每个区域有自己的坐标基点和座位矩阵。座位坐标用Canvas平面的绝对坐标记录，单位是像素，后端存坐标值，前端负责换算成屏幕位置。这样设计的好处是座位和坐标分离，后端不需要关心前端用什么库渲染，只要保证坐标数据准确即可。

渲染方案的选型上，我实测对比过SVG和Canvas。几千个座位以内，SVG开发效率高，DOM节点可控，比较好做事件绑定；但座位数破万之后，SVG的DOM节点太多，缩放和拖动会有明显卡顿。Canvas没有DOM节点，2万个座位做整体重绘也能维持在流畅级别，代价是点击命中需要自己做坐标换算——用户在Canvas上点到某个像素位置，要反算出这是哪个座位。这个换算其实不复杂，每个座位有固定的绘制矩形区域，遍历一遍命中判断即可，配合网格索引可以做到毫秒级。

3.2 选座接口协议设计

前后端交互协议我设计成三个接口，职责划分得很清楚：

• 获取座位图：GET /api/v1/seat-map?sessionId=xxx，返回区域列表和该场次所有可售座位坐标及状态。
• 锁座请求：POST /api/v1/seat-lock，请求体包含场次ID、座位ID列表、用户ID，返回每个座位的锁定结果。
• 创建订单：POST /api/v1/order/confirm，锁座成功后调用，传入锁座时的令牌和座位列表，生成待支付订单。

锁座成功后，前端会把对应的座位标成“已选”状态，但这只是本地的临时效果。真正要让其他用户看到这个座位被占用，依赖的是下一节讲的状态同步机制。另外我还做了一层前端防抖处理——用户点击座位后立即将按钮置灰，防止手抖重复提交。这个细节看起来不起眼，但在高并发场景下能显著降低无效请求对后端的压力。

3.3 座位状态实时同步：从轮询到局部推送

有人可能觉得座位状态全量刷新最简单，每个用户隔几秒拉一次座位图就行。但一场有2万座位、2000人在线的选座页面，全量刷新一次要传输几百KB数据，一分钟能打爆带宽。我的方案是分两级：

第一级是进入页面时全量加载一次座位图，这部分数据来自Redis缓存，响应控制在几十毫秒内。第二级是增量同步，锁座、支付成功、超时释放这些事件产生后，把变化的座位ID集合通过消息队列推送给在线用户，前端只更新这些座位的状态。增量推送的实现选了WebSocket，维护按场次区分的房间，后端收到状态变更事件后就向对应房间广播。

增量同步有一个老生常谈的坑：如果用户锁座成功了，但消息推送因为网络原因没送达，其他用户看到的座位状态就是旧的，点了之后后端会返回失败。所以我在前端做了失败重试提示，并且要求锁座接口在失败时返回具体原因，比如“座位已被锁定，请选择相邻座位”，这样前端可以立即刷新那一片区域的状态。这个体验兜底很重要，能减少很多客服压力。

4. 座位锁与库存扣减：防超卖、防重复锁定的并发控制方案

4.1 三种并发控制方案的实际对比

在做座位锁的方案选型时，我先把所有可能出现的技术路线都列了一遍，最终从并发能力、实现复杂度、跨进程支持三个维度做了取舍：

最终选了Redis分布式锁，考虑到两个实际因素。第一，票务系统必然是多实例部署，本地锁根本无法解决跨节点的锁竞争。第二，座位锁的粒度非常小，一个座位一把锁，Redis的读写性能完全能承受每秒上万次加锁操作。

但Redis锁不能替代数据库的状态判断。Redis锁解决的是“多个请求同时修改同一条记录的互斥问题”，数据库的WHERE status=1解决的是“状态是否合法的边界问题”，两者必须配合使用。先拿Redis锁保证同一时间只有一个请求在处理这个座位，再在数据库里执行带状态条件的更新，双重校验下才能做到既不超卖，又不重复锁定。

4.2 锁座接口的完整时序

锁座接口的核心代码逻辑如下：

public SeatLockResult lockSeat(Long sessionId, Long seatId, Long userId) { // 1. 加Redis分布式锁，锁粒度为一个座位 String lockKey = "seat:lock:" + sessionId + ":" + seatId; RLock lock = redissonClient.getLock(lockKey); boolean locked = lock.tryLock(3, 10, TimeUnit.SECONDS); if (!locked) { return SeatLockResult.fail(seatId, "座位太火爆，请稍后重试"); } try { // 2. 校验场次是否处于可售时间 if (!sessionService.isSaleOpen(sessionId)) { return SeatLockResult.fail(seatId, "该场次不在售票时间"); } // 3. 校验用户限购数量 if (!orderService.checkUserLimit(userId, sessionId)) { return SeatLockResult.fail(seatId, "超过限购数量"); } // 4. 数据库原子更新：可售 -> 锁定 int rows = seatMapper.lockSeatById(seatId, userId, new Date()); if (rows == 0) { return SeatLockResult.fail(seatId, "座位已被他人锁定"); } // 5. 刷新Redis座位状态缓存 seatCache.updateStatus(seatId, SeatStatus.LOCKED); return SeatLockResult.success(seatId); } finally { lock.unlock(); } }

数据库更新这条SQL是整个方案里最核心的一行：

UPDATE show_seat SET status = 2, locked_expire_time = DATE_ADD(NOW(), INTERVAL 15 MINUTE) WHERE id = #{seatId} AND status = 1

注意最后那个AND status = 1，它保证了状态从“可售”到“锁定”的转换在同一行更新里是原子的。两条并发请求都拿Redis锁，总有一个先拿到，先拿到的执行成功，后拿到的在Redis锁等待上排队，等它拿到锁去更新数据库时，UPDATE影响行数是0，直接返回“座位已被锁定”。

4.3 TTL、超时释放与批量恢复

锁座之后，最怕的就是座位被锁了但用户不付款。这里我把座位锁定的过期时间和订单支付有效时间设计成两段，中间留了缓冲。

• 座位锁定过期时间：15分钟
• Redis分布式锁的有效时间：10秒，配合Redisson看门狗自动续期
• 订单支付截止时间：15分钟

用户锁座成功后，必须在15分钟内完成支付。如果支付超时，系统在释放座位的同时把订单置为取消状态，座位重新回到可售池。

超时释放的兜底任务是一个定时扫描，分批执行，避免一次性更新大量行造成数据库阻塞：

UPDATE show_seat SET status = 1, order_id = NULL, locked_expire_time = NULL WHERE status = 2 AND locked_expire_time < NOW() LIMIT 500

这条SQL每30秒执行一次，每次处理500条，直到没有超时锁定的座位为止。除了定时扫描，我还接了一个延迟消息队列，锁座成功后立即投递一条15分钟后的释放消息，双保险兜底。定时扫描能处理消息丢失的场景，延迟消息能保证大多数座位到期后立即释放，不需要等扫描周期，两套机制缺一不可。

5. 订单状态机与支付超时回收：保证“钱”和“票”一致

5.1 订单状态机设计

订单状态机我把它画成了一组显式的流转规则，没有引入Spring StateMachine这类框架，因为这个场景的状态数不多，手写枚举驱动反而更直观、好维护。

订单状态定义如下：

状态流转的关键原则是：只能按图中箭头单向流转，不能跳转。比如从“待支付”直接跳到“已出票”是不允许的，必须先支付回调成功。每个状态变化都在代码里用条件判断保证：

// 支付回调场景：只有待支付或支付中的订单才能变成已支付 int rows = orderMapper.updateStatusByOrderNo( orderNo, OrderStatus.PAID.getCode(), Arrays.asList(OrderStatus.PENDING.getCode(), OrderStatus.PAYING.getCode()) ); if (rows == 1) { // 更新成功后，再变更座位状态和出票 seatMapper.updateStatusByOrderId(orderId, SeatStatus.SOLD); ticketService.issueTicket(orderId); }

5.2 支付回调幂等与对账

支付回调是最容易出问题的环节。支付网关发出通知后，因为网络抖动可能重试好几次，如果处理逻辑没有幂等性，同一笔订单可能被重复处理成已支付、重复出票。

幂等处理我做了两层。第一层是数据库约束，order_info表的order_no唯一索引，同一订单号永远只有一行；第二层是状态条件更新，UPDATE ... WHERE status IN (...)，只有当订单还处于待支付或支付中时才能更新成已支付，影响行数为0说明这条回调已经处理过了，直接返回成功。这两层叠加之后，就算回调消息重复10次，最终也只会执行一次出票逻辑。

资金对账方面，我加了一个每日对账脚本：拉取当天的支付流水和订单表，比对金额和状态。发现不一致的订单进入挂起状态，人工核查。这套机制不能少，因为支付回调本身也可能丢失，不能只依赖被动回调，必须主动对账把漏单捞出来。

5.3 出票与入场核验

支付成功后会生成电子票，核心内容是一个加密的票码，里面包含票号、场次ID、座位ID、校验签名。入场时闸机扫码，系统验签通过后，再校验票的状态是否为“已出票”，校验通过后更新为“已入场”，防止同一张票反复入场。

这里有个细节容易被忽略：退款时票不能直接作废，因为用户可能已经打印了纸质票或者截图保存了电子票，需要走线下核销。我的处理是选择退款的订单，票的状态变为“已退款”，入场核验时如果发现是已退款票，闸机直接拦截并提醒工作人员。线上线下的状态保持一致，要靠一个弱一致性的补偿任务定期同步，这也是稳定上线后运维的重点关注项。

6. 压测数据复盘与线上踩坑实录

6.1 压测场景与结果

系统测试阶段，我搭了一套模拟环境，配置是8核16G内存的虚拟机，MySQL 8.0，Redis单实例，应用部署两个节点。压测工具用的JMeter，主要压两个场景。

第一个场景：1000个线程并发随机选座，模拟正常抢票的随机分布。 第二个场景：2000个线程集中抢同一区域前排座位，模拟热点座位争抢。

实测结果如下：

TPS从1200降到850，是因为热点座位争抢导致大量请求阻塞在Redis锁等待上。但最关键的指标——超卖数——始终是0，这说明数据库的状态条件更新起到了预期作用。成绩归成绩，压测过程暴露出来的问题更多，下面几个坑非常值得记录。

6.2 死锁：加锁顺序不一致导致的数据库死锁

第一次压测强劲度场景时，数据库日志时不时报死锁错误。定位后发现是批量锁座的业务代码里，两个并发请求各自拿了不同座位的锁，然后又互相等待对方释放，形成了循环等待。

具体来说，请求A先锁座位1再锁座位2，请求B先锁座位2再锁座位1，两个请求各持有一把锁又等另一把，数据库检测到死锁后回滚其中一个事务。

修复方案很直接：所有批量锁座操作一律先按座位ID升序排序，再逐个加锁。这样所有请求的加锁顺序一致，从根源上消除了循环等待。这个教训不是票务系统特有的，所有需要批量加锁的业务都可能遇到，但票务系统因为锁粒度小、批量操作多，踩中的概率特别高。

6.3 Redis锁提前过期与看门狗问题

压测中还出现过一次诡异现象：A请求的锁座逻辑还没执行完，Redis锁先自动过期了，B请求趁虚而入拿到锁，也去更新这个座位，虽然最终数据库的条件更新兜住了没有超卖，但A请求后续的订单创建和座位状态修改发生了错乱。

根因是Redis锁的过期时间设置太短，只有5秒，而锁座事务在极端情况下执行超过5秒。修复办法是引入Redisson的看门狗机制，自动续期。同时把Redis锁的初始过期时间提高到10秒，看门狗每3秒检测一次，如果任务还在执行就续期。这样锁的生命周期和业务执行时间绑定，不会因为业务慢而被误杀。

6.4 缓存和数据库状态不一致的兜底方案

上线后遇到过座位状态在页面显示可选、提交后被提示已锁定的情况。排查下来是Redis座位状态缓存更新和MySQL事务的回滚不是原子的：先刷新了Redis，但数据库事务回滚了，缓存里留下了错误状态。

我的处理方案是调整更新顺序，先提交数据库事务，提交成功后再刷新缓存。同时增加一个兜底任务，每5分钟从数据库拉取全量座位状态，重建Redis缓存，确保即使某次缓存刷新失败，也能在几分钟内自我修复。这个兜底任务消耗不大，但带来的收益非常明显——线上选座页面的状态准确率能长期稳定在99.9%以上。

这套系统上线后实际跑了几场赛事，单场最高出票率99.7%，整场没有出现一次超卖。对我来说最有价值的收获，是在反复调整锁策略和状态同步机制的过程中，真正理解了“存量数据靠设计，状态一致性靠兜底”这句话的分量。如果再做一次，我会从第一天就把监控指标埋好，尤其是Redis锁等待时间、订单状态异常率和超时释放的队列积压量，这些指标能提前暴露问题，比事后翻日志高效得多。