1. 先把模拟订票这件事想清楚它到底在练什么火车模拟订票系统这个题目每年都会出现在各类课程设计和毕业设计的选题清单里。表面上看它就是个增删改查加个下单真动手写两周就会发现坑全埋在看不见的地方两个人同时买最后一张票怎么办、买了甲站到丁站的票会不会把乙站到丙站的座位吃掉、用户点了两次提交为什么出两张票、订单超时了库存怎么回滚。这些问题不解决系统跑起来是能跑但一演示就露馅。我自己前后带过几轮类似的项目也帮人改过不少半成品代码最深的感受是这个题目的价值不在于订票而在于模拟两个字背后那一整套业务约束。真实购票平台的核心难点是库存的区间占用和并发扣减模拟系统如果只是把车次和余票做成两个独立字段等于把最有技术含量的部分跳过去了答辩时老师随便问一句区间票怎么算就答不上来。所以这篇文章我打算按真实开发的顺序来讲需求边界怎么划、技术栈怎么选不踩坑、数据表怎么设计才不用后期打补丁、库存扣减的三种写法各适合什么场景、压测怎么把超卖问题逼出来、最后再聊聊开题报告怎么写才能扛住追问。适合的人群很明确正在做这个课设的同学、想拿它当毕设但不知道怎么做出深度的人、以及拿到一份别人写的源码想跑起来改一改的开发者。文中会给到可以直接抄的结构和代码片段也会说清楚哪些地方我踩过坑、哪些方案看着高级其实是给自己找麻烦。2. 需求边界与技术选型别为了炫技把工期拖死2.1 功能清单要先做减法新手最容易犯的错是一上来就把功能列表拉得跟真实购票平台一样长实名核验、改签、退票、候补、积分、发票、学生票优惠……列完之后发现光是把这些页面画出来就要一个月核心的库存逻辑反而没时间打磨。我的建议是按必做 / 加分 / 不做三档切分先保证必做部分能完整跑通一条链路再做加分项。档位功能模块说明必做用户注册登录、车次查询、余票展示、下单、模拟支付、订单列表、取消订单这条主链路不通系统等于没有必做乘车人管理、席别选择、选座可简化为偏好体现业务完整度加分区间票价计算、退票改签、订单超时自动取消能显著提升答辩分数加分后台车次管理、数据统计看板工作量好看实现成本低不做真实支付对接、短信验证、实名认证接口有合规风险且无技术增量这个划分的逻辑很简单必做部分是一条能走通的业务闭环加分部分是在这条闭环上增加分支。先把闭环跑通你才有底气在答辩时说我的系统能完整支撑一次购票行为而不是我做了二十个页面但下单会超卖。2.2 三套技术组合的横向对比选型这件事我的态度一直是选你熟悉的那套而不是选简历上想写的那套。下面三种组合我都见过实际落地的项目优缺点很分明。组合代表技术上手成本适合场景主要风险单体 Java 系某主流 Java 框架 持久层框架 关系库 模板引擎中课设、毕设需要体现分层与事务配置多环境问题会吃掉前两天Python 轻量系某 Python Web 框架 关系库 前端框架低时间紧、想快速出效果并发压测时性能瓶颈明显需要额外解释前后端分离后端接口服务 前端框架 关系库中高想同时展示前后端能力跨域、联调、部署三座大山我通常推荐单体 Java 系或前后端分离原因不是技术更好而是这两套在答辩场景下更好讲分层清晰、有事务概念、有拦截器和过滤器可以聊老师问你的并发怎么控制的你有东西可答。Python 轻量系做演示很快但如果被问到高并发下的库存一致性你需要额外花篇幅解释为什么选它反而被动。还有一点值得提醒别在课设里上微服务。我见过有同学把订票系统拆成用户服务、车次服务、订单服务、库存服务四个模块还要搞注册中心和网关最后卡在服务间调用超时上答辩前一天还在调配置。单体应用先把事务和锁讲明白比堆架构名词有价值得多。2.3 工程目录怎么摆目录结构不是形式主义它决定了你后期改代码时能不能三秒钟找到位置。我习惯按下面的方式组织前后端分离和单体都能套用train-ticket/ ├── src/main/java/com/example/ticket/ │ ├── controller/ 接口层只做参数校验和结果封装 │ ├── service/ 业务层事务边界在这里 │ │ └── impl/ │ ├── mapper/ 数据访问层 │ ├── entity/ 数据库实体 │ ├── dto/ 传输对象和实体分开 │ ├── config/ 全局配置、拦截器、线程池 │ └── common/ 统一返回、异常、常量、工具 ├── src/main/resources/ │ ├── mapper/ SQL 映射文件 │ ├── application.yml │ └── db/ 建表脚本和初始化数据 └── web/ 前端工程关键点在于dto 和 entity 必须分开。很多人图省事直接把数据库实体丢给前端结果前端能看到库存表的主键、版本号、内部状态字段后期想改字段名牵一发而动全身。多写一个转换类省下的是后面几十次改动的时间。3. 数据模型表设计错了后面全是补丁3.1 五张核心表撑起整个系统订票系统的表看着多真正不可省略的其实就五张车次表、区间库存表、订单表、订单明细表、乘车人表。用户表属于基础设施不展开说。-- 车次表一条记录代表一趟车 CREATE TABLE train ( id BIGINT PRIMARY KEY AUTO_INCREMENT, train_no VARCHAR(16) NOT NULL COMMENT 车次号如 G1001, start_station VARCHAR(32) NOT NULL, end_station VARCHAR(32) NOT NULL, depart_time DATETIME NOT NULL, arrive_time DATETIME NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1可售 0停运, UNIQUE KEY uk_no_date (train_no, depart_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 区间库存表核心中的核心 CREATE TABLE seat_stock ( id BIGINT PRIMARY KEY AUTO_INCREMENT, train_id BIGINT NOT NULL, travel_date DATE NOT NULL, seat_type VARCHAR(16) NOT NULL COMMENT 二等座/一等座/商务座, from_idx INT NOT NULL COMMENT 上车站序号, to_idx INT NOT NULL COMMENT 下车站序号, price DECIMAL(10,2) NOT NULL, total INT NOT NULL, sold INT NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0, UNIQUE KEY uk_seg (train_id, travel_date, seat_type, from_idx, to_idx), KEY idx_query (train_id, travel_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单表我建议把状态、金额、超时时间、幂等令牌都放进去一次性想清楚比后面加字段强CREATE TABLE ticket_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT 业务单号, user_id BIGINT NOT NULL, train_id BIGINT NOT NULL, travel_date DATE NOT NULL, seat_type VARCHAR(16) NOT NULL, from_idx INT NOT NULL, to_idx INT NOT NULL, amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已取消 3已退票, expire_at DATETIME NOT NULL COMMENT 支付截止时间, idem_key VARCHAR(64) NOT NULL COMMENT 幂等令牌, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), UNIQUE KEY uk_idem (user_id, idem_key), KEY idx_user (user_id, created_at), KEY idx_expire (status, expire_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有个细节值得单独说uk_idem这个唯一索引是防重复下单的最后一道闸。前端传一个随机令牌上来同一个用户拿同一个令牌提交两次第二次直接撞唯一索引报错业务层捕获后返回第一次的订单结果。这比在代码里查一遍再插入要可靠得多因为查-插之间存在时间窗口并发下挡不住。3.2 区间库存为什么不能只存一个余票数这是整个项目最有技术含量、也最容易被做错的地方。假设一趟车依次经过甲、乙、丙、丁四个站共 4 个座位。如果只维护一个remain 4的字段会发生什么用户 A 买了甲到丁的全程票扣减后remain 3。这个没问题。但如果用户 B 买甲到乙用户 C 买丙到丁这两个人其实是可以共用同一个座位的——B 下车后座位空出来给 C 坐。只维护一个总数字系统会认为卖了两张就少了两个座明明物理上还能多卖等于自己把运力浪费掉了。反过来更危险的情况总库存还剩 1用户 D 买乙到丙成功用户 E 买甲到丁也成功了因为系统只看总数不看区间结果 E 上车发现自己的座位被 D 占着。这就是典型的区间冲突超卖也是答辩最容易被问到的地方。正确的做法是把一趟车切成若干区间段每段独立维护库存。以上面的四站为例切成三段甲-乙、乙-丙、丙-丁。买甲到丁的票要把三段库存各扣一次买乙到丙的票只扣中段。这样任何时刻每段库存都代表这一段路上还有几个空位冲突自然就消解了。实际实现时from_idx和to_idx是站点在这趟车途经序列里的下标。查票时用户选的是甲到丙系统需要在库存表里找到覆盖这段的所有区间记录并取最小值作为可用余票。-- 查询甲(idx1)到丙(idx3)某席别的可用余票 SELECT MIN(total - sold) AS available FROM seat_stock WHERE train_id ? AND travel_date ? AND seat_type ? AND from_idx 1 AND to_idx 3;这段 SQL 的逻辑是一段行程能不能走通取决于它覆盖的每一小段都有空位所以取最小值。这个思路和很多真实系统的区间库存模型是一致的讲清楚这一点你的设计深度就上去了。3.3 席别和票价怎么组织票价不能简单写成车次上的一个字段因为同一趟车不同区间价格不同不同席别价格也不同。我一般让seat_stock表直接带上price初始化数据时按里程基数 × 席别系数算好写进去运行时直接读避免每次查询都做计算。席别系数说明二等座1.0基准价一等座1.6座位宽、间距大商务座3.1数量少价格高系数只是模拟用重点是票价 区间里程基数 × 席别系数四舍五入到分。这个计算过程要在文档里写清楚因为老师很可能会问你的票价怎么来的你能答出公式和取整规则说明你是想过的不是随便填的数。4. 核心链路实操从查票到出票4.1 查票接口索引、连表和缓存的取舍查票是整个系统里 QPS 最高的接口也是压测时最先扛不住的地方。它的逻辑本身不复杂按出发站、到达站、日期筛出符合条件的车次再关联库存表算出余票和最低价。我一开始写的版本是三条 SQL 串行查先查车次列表再循环查每个车次的库存最后拼装。数据量小的时候完全没问题压测一上来就崩了典型 N1 查询。改成一次关联查询之后接口耗时从 300ms 降到 40ms 左右。SELECT t.id, t.train_no, t.depart_time, t.arrive_time, s.seat_type, s.price, MIN(s.total - s.sold) AS available FROM train t JOIN seat_stock s ON s.train_id t.id WHERE t.status 1 AND s.travel_date #{date} AND s.from_idx #{fromIdx} AND s.to_idx #{toIdx} GROUP BY t.id, s.seat_type ORDER BY t.depart_time;索引方面seat_stock上的idx_query (train_id, travel_date)是必须的train表上的uk_no_date唯一索引顺带承担了按车次号加日期查询的职责。这两个索引不加几万条数据就能让查询慢到肉眼可见。注意不要在seat_stock上对from_idx、to_idx单独建索引。区分度太低优化器大概率不会走反而增加写入成本。真正有效的是联合索引把高基数字段放前面。至于缓存我的建议是课设阶段先别上。加一层缓存意味着要处理缓存与数据库的一致性库存扣减完还得删缓存一旦漏删就会出现页面显示有票、下单提示无票的尴尬。等你把主链路跑通、压测数据出来了如果确实 QPS 顶不住再考虑对车次这种低频变动的数据做缓存库存这种高频变动的老老实实走数据库。4.2 下单库存扣减的三种写法与取舍下单是并发冲突最集中的地方也是最能体现功力的部分。下面三种写法我都实际用过各有适用场景。第一种先查后改最朴素也最容易翻车。// 错误示范查和改之间存在时间窗口 SeatStock stock stockMapper.selectById(id); if (stock.getTotal() - stock.getSold() 1) { stock.setSold(stock.getSold() 1); stockMapper.updateById(stock); }问题很明显两个线程同时查到余票为 1都判断通过都执行更新最后卖出两张。这在压测里几乎百分百复现只要并发数超过 20 就能稳定超卖。这种写法只能用在单机单线程的教学演示里千万别放到正式代码里。第二种带条件的原子更新也就是乐观锁。Update(UPDATE seat_stock SET sold sold 1 WHERE id #{id} AND total - sold #{count}) int deductStock(Param(id) Long id, Param(count) int count);业务层判断返回值等于 1 说明扣减成功等于 0 说明库存不足直接抛业务异常回滚事务。这个写法的好处是不需要显式加锁靠数据库的行锁保证原子性WHERE条件在更新时再做一次判断天然防住了并发窗口。我实际压测下来这种写法在 200 并发下表现稳定没有出现一次超卖。代价是高并发时会有大量更新失败需要重试不过在订票场景下失败本来就该提示用户余票不足不需要重试所以这个代价可以接受。第三种悲观锁SELECT ... FOR UPDATE最稳但吞吐最低。SELECT * FROM seat_stock WHERE train_id ? AND travel_date ? FOR UPDATE;拿到行锁之后再判断再更新逻辑最直观。但它的问题在于锁持有的时间包含整个业务判断过程并发一高就是排队QPS 上不去。而且如果事务里还有别的远程调用锁会持有很久容易拖垮整个库。我的取舍是下单扣库存用第二种退票回滚库存也用第二种sold sold - count只有涉及多段库存同时扣减、必须保证全成功或全失败的场景才用事务包起来靠事务回滚兜底。这样既保证了正确性又不至于把性能压死。多段扣减的实现要点在于买甲到丁的票要扣三段库存这三段必须在一个事务里完成任何一段失败就整体回滚。Transactional(rollbackFor Exception.class) public OrderVO createOrder(CreateOrderDTO dto) { ListSeatStock segments stockMapper.listSegments( dto.getTrainId(), dto.getTravelDate(), dto.getSeatType(), dto.getFromIdx(), dto.getToIdx()); if (segments.isEmpty()) { throw new BizException(该区间无可用库存记录); } // 按 id 升序扣减避免多订单交叉扣减造成死锁 segments.sort(Comparator.comparing(SeatStock::getId)); for (SeatStock seg : segments) { int rows stockMapper.deductStock(seg.getId(), dto.getCount()); if (rows 0) { throw new BizException(余票不足请重新选择); } } // ... 落订单、写明细、返回 }这里有个很容易被忽略的细节扣减顺序必须统一。如果订单 A 先扣段 1 再扣段 2订单 B 先扣段 2 再扣段 1两者并发就会互相等待形成死锁。统一按主键升序扣减破坏循环等待条件死锁概率会降到极低。这个点在答辩时讲出来加分效果很好。4.3 订单状态机把超时取消做成闭环订单状态如果随便用数字乱塞后期一定会出现已取消的订单又被支付了这种脏数据。我习惯先画清楚状态流转再写代码。当前状态触发动作目标状态校验条件待支付支付成功已支付未超过 expire_at待支付用户取消已取消无待支付超时已取消已过 expire_at已支付申请退票已退票距发车时间大于阈值已取消任何动作不允许终态关键点在于每次状态变更都要带上原状态作为条件而不是先查再改。这样即使两个请求同时到达也只有一个能成功。UPDATE ticket_order SET status 1 WHERE order_no ? AND status 0 AND expire_at NOW();影响行数为 0 就意味着订单已经被取消或者已经超时直接提示用户订单已失效不需要额外加锁。超时取消的实现课设阶段我推荐用定时任务扫描简单可靠Scheduled(fixedDelay 60000) public void cancelExpiredOrders() { ListTicketOrder expired orderMapper.listExpired( LocalDateTime.now(), 200); for (TicketOrder order : expired) { // 状态机更新防止与用户手动支付冲突 int rows orderMapper.cancelIfPending(order.getId()); if (rows 1) { stockMapper.releaseStock(order); } } }cancelIfPending的 SQL 里同样带AND status 0和支付接口形成互斥。库存释放放在状态更新成功之后保证一条订单只回滚一次库存。批量大小限制在 200 条避免一次扫太多把库压住。提示定时任务的执行周期别设得太短一分钟一次足够。设成每秒一次在数据量大的时候会和其他业务争抢连接池反而拖慢下单接口。4.4 模拟支付与幂等处理真实的支付对接有合规风险课设里做一个模拟支付页就够了展示订单号、金额、倒计时点确认支付调用后端接口改状态。这里必须处理幂等。用户手抖点两下或者网络超时前端重试都可能发两次支付请求。处理方式和前面一样靠状态机条件更新第二次进来时status已经不是 0 了影响行数为 0直接返回订单已支付前端展示同样的成功页面。public PayResult pay(String orderNo) { int rows orderMapper.payIfPending(orderNo, LocalDateTime.now()); if (rows 1) { return PayResult.success(支付成功); } TicketOrder order orderMapper.selectByNo(orderNo); if (order null) { throw new BizException(订单不存在); } if (order.getStatus() 1) { return PayResult.success(订单已支付); } throw new BizException(订单状态异常无法支付); }这个模式的通用名字叫幂等表 状态机凡是涉及钱和库存的操作都该这么写。我见过太多项目在这一步偷懒结果演示时不小心点了两下订单列表里出现两条一模一样的已支付记录场面很尴尬。5. 并发与一致性压测暴露出来的真实问题5.1 压测怎么做才有意义很多人对压测的理解是跑一下看看能撑多少并发其实压测的价值在于制造并发冲突把隐藏的 bug 逼出来。订票系统最该压的就是秒杀场景放 100 张票用 300 个并发线程去抢。我的做法是准备一个固定的测试数据集一趟车、一个日期、一个席别、100 张库存然后用压测工具配置 300 个线程、循环 1 次、集合点设置在扣减前让请求尽可能同时到达。指标优化前优化后说明成功下单数118100优化前超卖 18 单平均响应时间210ms85ms去掉 N1 查询最大响应时间3.2s640ms减少锁等待错误率0%0%库存不足属于业务返回不算错误优化前那 118 单就是最好的证据。把这个对比数据放进文档里比写十页系统支持高并发都有说服力因为它证明了你真的复现过问题并且修复了。5.2 超卖的三种成因与对应解法超卖不是单一原因造成的我遇到过三种每种解法不一样。成因一判断和更新分离。就是前面说的先查后改解法是改成带条件的原子更新把判断塞进WHERE里。成因二Redis 扣减和数据库不同步。有些同学为了性能先在缓存里扣减再异步写库结果缓存扣成功了、写库失败了库存凭空消失。课设阶段我的建议是别引入这一层数据库扛得住就用数据库简单可靠。真要上缓存必须配合消息队列和补偿机制工作量翻倍。成因三事务隔离级别导致的脏读。默认的可重复读级别下一个事务里多次查询看到的是快照如果扣减逻辑依赖事务内的查询结果就可能基于过期数据做判断。解决办法就是彻底不用事务内查询 判断这套改成原子更新根本不给快照发挥作用的机会。5.3 一人多单和重复提交同一用户短时间内连点会生成多个待支付订单各自占着库存。如果用户不付款这些库存要等超时才释放等于白白被锁住。处理思路分两层。前端层做按钮防抖点击后立刻禁用请求返回再恢复。后端层的兜底是限制同一用户对同一车次同一天的有效订单数比如最多 3 个待支付订单超过就提示先处理已有订单。int pending orderMapper.countPending(userId, trainId, travelDate); if (pending 3) { throw new BizException(您有未完成的订单请先支付或取消); }这个限制在真实系统里也有对应逻辑防止恶意占座讲出来既有业务合理性也体现了你想过滥用场景。6. 开题报告怎么写才扛得住追问6.1 标准骨架和每部分的分量开题报告的格式各校要求不同但核心结构大同小异。我按重要性排个序告诉你哪部分值得多花时间。章节建议占比写作要点研究背景与意义15%说清楚为什么做模拟系统而不做真实系统避开合规国内外研究现状20%讲技术方案演进别堆人名和年份研究内容与目标25%逐条列出功能模块可量化技术路线与方案25%架构图、技术选型理由、关键难点进度安排10%按周拆留出两周缓冲参考文献5%近五年的为主技术书籍和期刊混合最容易写砸的是研究现状很多人写成某某年某某提出了某某系统读起来像流水账。我的建议是按技术维度组织库存并发控制这块有哪几类方案、订单幂等有哪几种做法、区间库存建模有几种思路每种说清楚优缺点和适用场景最后落到本课题选择某某方案理由是某某。这样写出来有观点不是资料的搬运。研究内容部分一定要可量化。实现车次查询功能这种表述太虚支持不少于 30 趟车次、5 个途经站点的区间库存管理单趟车次单次查询响应时间小于 200ms就好得多。老师看到具体数字会觉得你心里有谱。6.2 技术路线里必须讲清楚的三件事第一件是架构选择。为什么用单体不用微服务理由要具体系统规模小、部署环境有限、事务一致性要求高、开发周期紧。这些理由都成立写出来显得理性。第二件是库存模型。这是你的核心技术点要配一张示意图用文字描述或者表格代替别用复杂图表说明区间是怎么切分的、余票怎么推导的、扣减怎么保证原子性。这块写透答辩时就是你的主场。第三件是并发方案。说清楚你用了乐观锁还是悲观锁、为什么这么选、怎么验证有效压测数据。这是把做了个系统提升到解决了一个问题的关键。6.3 常见追问和应答思路我把带过的项目里被问到的频率最高的问题整理成表提前准备好答案现场就不慌。追问应答思路你的系统和真实平台差距在哪主动承认差距列出真实系统的额外能力风控、多机房、余票预测说明本课题聚焦在库存一致性这一点做深区间库存为什么不用位图位图适合固定少量座位的场景区间库存涉及票价、席别、动态增减站点用表更灵活位图方案可以提一句作为优化方向乐观锁失败率高怎么办说明订票场景失败本来就是正常业务返回不需要重试如果确实需要可以加短暂退避重试定时任务扫全表会不会慢说明有(status, expire_at)联合索引且限制批量大小实际数据量下毫秒级为什么不做分布式说明单体已能满足需求引入分布式会带来一致性复杂度不符合课题目标7. 常见问题排查速查表这部分是从实际调试中攒下来的都是些文档里不写、但一定会遇到的问题。现象大概率原因排查动作下单必然提示库存不足区间下标算错from_idx ? AND to_idx ?范围写反打印实际查询的区间参数和库存表里的记录逐条比对余票显示有但下单失败查询取 MIN 逻辑正确但扣减时某一段库存为 0把扣减的每段返回行数打日志定位是哪一段失败支付成功但订单列表没变前端没刷新或状态字段映射错误直接查库看 status再看前端字典映射定时任务不执行启动类没加开启注解或任务类没被扫描到启动日志搜任务注册信息中文乱码数据库连接串没指定字符集连接串加characterEncodingutf8建表用 utf8mb4跨域请求失败前端端口和后端不一致没配跨域后端加全局跨域配置别在每个接口上单独加事务不回滚抛的是受检异常或方法内部自己 try-catch 吞了事务注解加rollbackFor Exception.class检查 catch 块压测时连接池耗尽连接数配置太小或连接没释放调大连接池检查是否有手动获取连接未关闭的地方我重点说两个最容易耗时间的。第一个是区间下标算错这个错的隐蔽性极强因为 SQL 不报错只是查不到数据表现出来就是明明有票却提示无票。我的习惯是在初始化数据时把站点顺序打印成一行日志写代码时对照着看比反复猜要快得多。第二个是事务不回滚。很多人写完Transactional发现数据还是脏的八成是方法内部try-catch把异常吃掉了或者抛的是受检异常而注解没配rollbackFor。还有个更隐蔽的情况同类内部方法互相调用事务注解不生效因为走的是 this 调用而不是代理对象。这个坑我踩过排查了整整一个下午。提示判断事务是否生效最直接的办法是在方法里打一行日志然后在事务提交后再打一行看两行的顺序。如果业务日志在提交日志之后说明事务根本没起作用。8. 源码交付与二次开发建议8.1 拿到一份源码先做什么如果你是从别人手里接过的项目别急着一头扎进代码里。我的顺序是先看建表脚本再看配置文件最后看 controller。表结构能告诉你这个系统的数据模型是什么水平配置文件告诉你依赖了什么组件controller 告诉你功能边界在哪。三个看完心里就有数了。跑起来的顺序也讲究先把数据库建好、初始化数据灌进去再改配置文件里的连接信息然后打包运行。中间任何一步报错先去日志里找第一个异常不要被后面的连锁报错带偏。我见过有人盯着最后一行NullPointerException调了半天实际根因在前面几百行的连接失败上。8.2 二次开发往哪加如果你的项目要往上做深度我建议从这三个方向挑一个方向一余票预测。基于历史订单数据给每个车次算一个售罄概率在列表页显示预计紧张标签。技术上加一个统计任务和一张统计表就行但业务价值讲起来很好听。方向二候补队列。用户买不到票可以排队有人退票就按顺序通知。这个功能涉及队列、通知、超时失效工作量适中能体现你对异步流程的理解。方向三改签。改签本质上是退旧票 买新票的组合但要保证原子性还要处理差价。这个最考验事务设计做好了是亮点做不好容易出脏数据。我个人推荐从候补队列入手因为它对主链路侵入小可以独立成一个模块即使做不完也不影响主体功能。8.3 答辩演示的脚本设计演示最忌讳现场乱点。提前写好脚本按顺序走一遍控制在 5 分钟内用普通用户登录查某天某区间的车次展示余票和票价30 秒选一个车次下单故意不支付展示订单进入待支付40 秒另开一个浏览器窗口用另一个账号抢最后一张票展示库存不足提示60 秒回到第一个窗口完成支付展示订单状态变化30 秒等待超时时间到展示另一个未支付订单被自动取消、库存回滚60 秒打开压测报告展示优化前后的数据对比60 秒第 3 步和第 5 步是整个演示的高光因为它们直观展示了并发控制和状态机比讲十分钟架构图管用。超时时间为了演示可以临时配成 2 分钟正式配置还是 15 分钟这个在演示前改一下配置就行。我在实际带项目的过程中体会最深的一点是这个题目做得好不好跟你写了多少页面关系不大跟你有没有把一张票从查询到出票再到回滚这条链路上的每个边界想清楚关系极大。很多人卡在最后一周不是功能没写完而是发现库存数据乱了、订单状态对不上回头改表结构牵一发动全身。提前把区间库存、状态机、幂等这三件事想明白后面就是体力活。还有个小技巧分享一下调试并发问题的时候别用 debug 断点断点会把并发时序打乱问题反而复现不出来直接在关键位置打日志用时间戳看执行顺序比什么都准。
