简介这份PPT资源面向计算机专业学生与Java Web开发者围绕五台山景点购票系统的设计与实现展开可作为毕业设计、课程设计或SSM框架学习项目的参考方案。内容涵盖系统背景、需求分析、SSM框架选型、管理员与用户功能模块划分、系统测试及结论等完整开发流程并记录了页面显示、数据库连接等实际开发难题的解决思路。资源包共1个pptx文件大小约3.17MB以幻灯片形式呈现论文结构与系统分析要点便于快速浏览与课堂汇报。目前已有71人学习下载。读者可从中获取B/S架构购票系统的整体设计思路、SpringSpringMVCMyBatis框架的落地方式以及景点、酒店、客房预订等模块的功能规划参考适合需要撰写相关论文或搭建同类旅游管理系统的开发者借鉴。1. 五台山景点购票系统从一份答辩PPT到能跑通的预约排队方案很多做景区票务的同行都遇到过这种场景需求方丢过来一份《五台山景点购票系统.pptx》里面画了十几页界面草图写着“在线选时段、实名预约、分时入园、退改签”但真正落到代码层面库存怎么扣、并发怎么扛、订单超时怎么回收一个字没提。这份PPT本质上是一份需求意向书不是技术方案。我见过太多团队照着PPT直接开写结果上线第一天就超卖或者高峰期接口全红。这篇笔记就按我实际做过的景区票务系统路子把这份PPT背后的技术栈、数据模型、核心接口和踩坑点拆开讲。适合正在做景区预约、演出票务、场馆分时预约的开发者也适合需要把一份产品PPT翻译成可执行工程方案的技术负责人。核心就三件事时段库存模型、下单链路、防超卖。2. 把PPT里的“分时预约”翻译成数据库表四个核心表与字段取舍2.1 为什么不能只用一张ticket表扛所有库存PPT上通常只画一个“选择日期和时段”的控件看起来简单但背后至少涉及四个维度的数据景点/景区、票种成人/学生/老人、日期、时段。如果只用一张表存“某天某票种剩余数量”遇到五台山这种多入口南门、西门、北门、多景点显通寺、塔院寺、菩萨顶的场景库存粒度根本不够用。常见做法是拆成四张表景区表、票种表、时段库存表、订单表。时段库存表是核心每一行代表“某景区某票种某日期某时段”的可售数量。这样拆的好处是扣减库存时锁定的行非常明确不会出现跨景点互相干扰。字段设计上时段库存表我一般会加这几个关键列stock_total总库存、stock_sold已售、stock_locked锁定中用于待支付订单、version乐观锁版本号。不要用stock_remain这种计算字段直接存因为并发下你没法保证remain total - sold - locked这个等式永远成立。用三个独立字段每次扣减只更新sold或locked对账时再算剩余。票种表里要加need_realname是否实名和refund_rule退改规则JSON这两个字段决定了后续下单接口的分支逻辑。2.2 建表SQL与索引把查询和扣减分开设计-- 景区表 CREATE TABLE scenic_spot ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(64) NOT NULL COMMENT 景点名称, parent_id BIGINT DEFAULT 0 COMMENT 父级景区0为顶级, open_time TIME NOT NULL, close_time TIME NOT NULL ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 票种表 CREATE TABLE ticket_type ( id BIGINT PRIMARY KEY AUTO_INCREMENT, spot_id BIGINT NOT NULL, name VARCHAR(32) NOT NULL COMMENT 成人票/学生票, price DECIMAL(10,2) NOT NULL, need_realname TINYINT DEFAULT 1 COMMENT 1需要实名, refund_rule JSON COMMENT 退改规则, INDEX idx_spot (spot_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 时段库存表核心 CREATE TABLE stock_slot ( id BIGINT PRIMARY KEY AUTO_INCREMENT, spot_id BIGINT NOT NULL, ticket_type_id BIGINT NOT NULL, visit_date DATE NOT NULL, time_slot VARCHAR(16) NOT NULL COMMENT 如08:00-10:00, stock_total INT NOT NULL DEFAULT 0, stock_sold INT NOT NULL DEFAULT 0, stock_locked INT NOT NULL DEFAULT 0, version INT NOT NULL DEFAULT 0, UNIQUE KEY uk_slot (spot_id, ticket_type_id, visit_date, time_slot), INDEX idx_date (visit_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 订单表 CREATE TABLE ticket_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE, user_id BIGINT NOT NULL, stock_slot_id BIGINT NOT NULL, quantity INT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已取消 3已退款, expire_time DATETIME NOT NULL COMMENT 支付超时时间, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_user (user_id), INDEX idx_status_expire (status, expire_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明stock_slot上的唯一索引uk_slot是防重复扣减的第一道防线同一景区同一票种同一天同一时段只允许一行记录。version字段用于乐观锁更新时带上version条件。订单表的idx_status_expire索引专门给定时任务扫超时订单用没有这个索引订单量上来后扫表会拖垮数据库。参数上time_slot用字符串而不是时间范围是因为景区时段通常是固定枚举08:00-10:00、10:00-12:00字符串比较更直观也方便前端直接展示。2.3 库存初始化与日常维护的脚本库存不是写死的每天凌晨要生成未来第N天的库存记录。常见做法是用定时任务跑一个初始化脚本从票种表读取每个票种的每日总库存然后按日期和时段拆分成多行插入stock_slot。如果某天临时闭园或调整库存直接更新对应行的stock_total但要注意已经售出的部分不能小于新的总库存。# 库存初始化脚本伪代码按天生成未来7天库存 import datetime from models import TicketType, StockSlot def init_stock(days_ahead7): today datetime.date.today() slots [08:00-10:00, 10:00-12:00, 13:00-15:00, 15:00-17:00] for ticket in TicketType.query.all(): for i in range(days_ahead): visit_date today datetime.timedelta(daysi) for slot in slots: # 每个时段平均分配总库存也可按比例配置 per_slot ticket.daily_stock // len(slots) StockSlot.get_or_create( spot_idticket.spot_id, ticket_type_idticket.id, visit_datevisit_date, time_slotslot, defaults{stock_total: per_slot} )这段脚本的关键点是get_or_create避免重复初始化时插入冲突。per_slot的分配策略可以改成按历史流量比例比如上午时段占40%下午占60%。如果PPT里写了“分时预约”那库存初始化就必须按时段拆分不能只按天。3. 下单接口的防超卖设计乐观锁、Redis预扣与消息队列的取舍3.1 为什么直接update set stock_sold stock_sold 1会翻车很多新手写扣库存就是一句UPDATE stock_slot SET stock_sold stock_sold 1 WHERE id ?然后判断影响行数。在低并发下没问题但景区放票瞬间QPS可能上千数据库行锁会让请求排队响应时间飙升。更严重的是如果先查库存再更新两个请求同时查到剩余1张都去更新就会超卖。血泪经验是扣减操作必须是一条原子SQL并且带上库存充足的条件。-- 原子扣减锁定库存带条件更新 UPDATE stock_slot SET stock_locked stock_locked #{quantity}, version version 1 WHERE id #{slotId} AND stock_total - stock_sold - stock_locked #{quantity} AND version #{version};这条SQL的影响行数为1才表示锁定成功为0表示库存不足或版本冲突。版本冲突时需要重试一般重试3次。注意stock_total - stock_sold - stock_locked这个表达式在WHERE里是对当前行求值InnoDB会加行锁所以并发下是安全的。但行锁意味着同一时段的请求会串行化如果单时段库存只有几百张QPS又高数据库压力会很大。3.2 Redis预扣减库存把流量挡在数据库之前更稳的做法是在Redis里做预扣减数据库只做最终落账。流程是系统启动时把每个时段的库存加载到Redis用DECRBY原子扣减扣减成功后再异步写数据库。Redis的DECRBY是单线程原子操作不会超卖。但要注意Redis和数据库的一致性如果Redis扣了但数据库写失败需要补偿。常见方案是用消息队列扣减Redis成功后发一条消息消费者负责写数据库和创建订单。如果写库失败消息重试同时把Redis库存加回去。# Redis预扣减 消息队列异步落库 import redis, json r redis.Redis() def pre_deduct(slot_id, quantity, user_id): key fstock:{slot_id} # 先判断剩余再扣减用Lua脚本保证原子性 lua local stock redis.call(GET, KEYS[1]) if not stock then return -1 end if tonumber(stock) tonumber(ARGV[1]) then return 0 end redis.call(DECRBY, KEYS[1], ARGV[1]) return 1 result r.eval(lua, 1, key, quantity) if result 1: # 发送消息到队列异步创建订单 mq.publish(order_create, json.dumps({ slot_id: slot_id, quantity: quantity, user_id: user_id })) return True return FalseLua脚本保证了“判断扣减”的原子性避免先GET再DECRBY之间的竞态。result为-1表示Redis里没有这个key需要回源数据库加载。消息队列的消费者要幂等因为消息可能重复投递订单号可以用slot_iduser_id时间戳生成唯一值。3.3 支付超时与库存回滚别让锁定库存变成死库存用户下单后未支付锁定库存必须释放。常见做法是订单创建时写一个expire_time比如15分钟后然后起一个定时任务每分钟扫一次status0 AND expire_time now()的订单批量取消并回滚库存。回滚时要注意如果Redis预扣减和数据库落库都做了两边都要回滚。数据库回滚用stock_locked stock_locked - quantityRedis用INCRBY加回去。定时任务要加分布式锁避免多实例重复执行。-- 超时订单取消并回滚库存事务内执行 START TRANSACTION; UPDATE ticket_order SET status 2 WHERE id ? AND status 0; -- 影响行数为1才回滚库存 UPDATE stock_slot SET stock_locked stock_locked - ? WHERE id ?; COMMIT;注意status 0这个条件不能少防止已支付订单被误取消。回滚库存的SQL也要带条件确保不会把sold扣成负数。4. 实名预约与退改签PPT上没写的规则引擎怎么落地4.1 实名信息校验的三种模式与字段设计五台山这类景区通常要求实名预约但实名程度不同有的只要求填身份证号有的要求人脸识别有的要求同行人全部实名。PPT上一般只写“实名预约”四个字实际落地要区分。我一般把实名模式做成票种表的一个字段realname_mode0不实名、1仅下单人实名、2所有游客实名。订单表里加一个visitor_infoJSON字段存游客列表。校验逻辑放在下单接口里根据realname_mode决定校验强度。# 实名校验逻辑 def validate_realname(ticket_type, visitors): mode ticket_type.realname_mode if mode 0: return True if mode 1: # 只校验下单人 return bool(visitors[0].get(id_card)) if mode 2: # 所有游客都要有身份证号 return all(v.get(id_card) for v in visitors) return Falsevisitors是一个列表每个元素包含name、id_card、phone。身份证号要做格式校验但不要做真实性校验那是公安接口的事。如果PPT里写了“刷脸入园”那还要在订单里存人脸照片的URL但照片存储涉及隐私合规一般只存哈希值或第三方平台的流水号。4.2 退改签规则引擎用JSON配置代替硬编码退改签规则是票务系统里最容易写死的地方。PPT上可能只写“支持退票”但实际规则可能是游玩当天前2小时可免费退前1小时收20%手续费过后不可退。这种规则如果硬编码在代码里每改一次就要发版。常见做法是用JSON配置规则存在票种表的refund_rule字段里退票时解析JSON计算手续费。{ refundable: true, rules: [ {hours_before: 24, fee_rate: 0}, {hours_before: 2, fee_rate: 0.2}, {hours_before: 0, fee_rate: 1.0} ] }退票接口根据当前时间与visit_date time_slot的开始时间计算小时差匹配第一条hours_before小于等于该差值的规则取fee_rate计算手续费。fee_rate为1.0表示不可退。这个JSON结构简单运营人员也能看懂改规则不用动代码。4.3 退票接口的库存回滚与对账退票成功后库存要回滚到对应时段。注意如果退的是已支付订单回滚的是stock_sold如果退的是待支付订单虽然少见回滚的是stock_locked。回滚后要更新Redis里的库存否则Redis和数据库不一致。对账脚本每天跑一次检查stock_total - stock_sold - stock_locked是否等于Redis里的剩余库存不一致就告警。-- 退票回滚库存已支付订单 UPDATE stock_slot SET stock_sold stock_sold - #{quantity} WHERE id #{slotId} AND stock_sold #{quantity};stock_sold #{quantity}这个条件防止回滚过多导致负数。如果影响行数为0说明数据异常需要人工介入。5. 避坑与排查景区票务系统上线后最容易翻车的五个点5.1 时段库存初始化时漏掉节假日现象节假日当天所有时段显示“已售罄”但实际库存充足。原因库存初始化脚本只生成了未来7天的库存节假日提前一个月放票脚本没覆盖到。解决初始化脚本的days_ahead参数改成可配置节假日通过后台手动触发批量生成或者把days_ahead默认调到30天。5.2 Redis预扣减后消息丢失导致库存少卖现象Redis显示有库存但数据库里没有对应订单用户支付后无法入园。原因消息队列投递失败或消费者宕机Redis扣了但数据库没落账。解决消息队列开启持久化消费者手动ACK同时加一个补偿任务对比Redis和数据库的库存差异差异超过阈值时自动回滚Redis库存。5.3 订单超时回滚时把已支付订单误取消现象用户明明支付成功了订单却被取消库存被释放。原因定时任务扫超时订单时没有排除已支付状态或者支付回调延迟导致订单状态还没更新。解决取消订单的SQL必须带status 0条件支付回调接口要加锁防止并发更新。另外支付回调里要把expire_time置空或设为一个极大值避免被定时任务扫到。5.4 实名信息JSON字段查询性能差现象后台按身份证号查订单时全表扫描响应超过5秒。原因visitor_info是JSON字段没有索引LIKE %身份证号%无法走索引。解决如果实名查询是高频需求把身份证号单独存一列id_card_hash加索引。或者用MySQL 5.7以上的JSON函数建虚拟列索引。5.5 退票手续费计算时区错误现象用户提前24小时退票却被收了20%手续费。原因服务器时区是UTCvisit_date time_slot按UTC计算与用户本地时间差8小时。解决所有时间计算统一用用户所在时区或者数据库存UTC时间计算时先转成东八区。最简单的方法是在应用层用pytz或zoneinfo做时区转换不要依赖数据库的NOW()。6. 从PPT到上线一个可复用的压测脚本与库存对账技巧压测是验证防超卖设计的唯一手段。我一般用Locust写一个简单的压测脚本模拟1000个用户同时抢同一个时段的100张票看最终订单数是否等于100。脚本核心是并发调用下单接口然后统计成功订单数和库存剩余。# Locust压测脚本简化版 from locust import HttpUser, task, between import random class TicketUser(HttpUser): wait_time between(0.1, 0.5) task def grab_ticket(self): slot_id 1 # 固定抢同一个时段 payload { slot_id: slot_id, quantity: 1, user_id: random.randint(10000, 99999) } with self.client.post(/api/order/create, jsonpayload, catch_responseTrue) as resp: if resp.status_code 200 and resp.json().get(code) 0: resp.success() else: resp.failure(下单失败)跑完压测后查数据库SELECT stock_total, stock_sold, stock_locked FROM stock_slot WHERE id 1再查订单表里status IN (0,1)的订单总数。如果stock_sold stock_locked不等于订单总数说明有超卖或漏扣。这个对账习惯我每次上线前必做比看日志管用。另一个技巧是给库存表加一个last_update_time字段每次扣减更新这个时间。对账时如果发现某个时段的last_update_time很久没变但库存对不上说明可能有脏数据。压测环境要和生产环境隔离但数据库配置要一致否则压测结果没有参考价值。最后说一个我踩过的坑压测时用了SELECT ... FOR UPDATE手动锁库存结果压测QPS只有200数据库CPU跑满。后来改成乐观锁重试QPS提到1500。所以能不用悲观锁就不用乐观锁重试次数控制在3次以内超过就返回“系统繁忙”让用户重试。这个方案不一定适合所有场景但对于景区票务这种库存粒度细、并发集中在放票瞬间的业务够用了。希望帮到你。本文还有配套的精品资源点击获取