简介这是一份面向景区票务管理人员、系统维护人员及信息化建设者的电子票务系统操作手册。文档以模块化方式梳理了售票、退票、基本信息与记录管理四大核心板块详细涵盖散客售票、导游卡与员工卡办理、会员卡注册补办续期、条码票登记、退票流程、设备信息维护、开发提示与显示屏信息、票种设置、散客票信息、导游卡信息、会员资料及各类记录查询等操作细节并配有异常处理与记录管理说明能帮助用户按流程快速掌握从购票到退票的全链路操作减少上线培训成本。资源包含1个doc格式文档压缩包大小12.48MB便于下载后直接查阅或打印。目前已有264人学习下载适合刚引入电子票务系统的中小景区或正在升级票务流程的运营团队参考使用。1. 景区电子票务系统使用说明真正的难点不在卖票而在状态一致性景区电子票务系统看着像一套常见的电商交易软件实际用起来最折磨人的不是下单支付而是线下设备与线上订单的状态对齐。游客在第三方平台买的电子票到闸机口扫码那一下系统要在几百毫秒内完成订单核验、防重复核销、票种匹配和状态回写这些动作一旦因为网络抖动或缓存失效卡住门口就会排起长队。这套系统管理的不只是订单而是库存、渠道、设备、财务四件事的联动窗口卖出去的票不能让 OTA 再卖同一张闸机已经核销的票不能进入退款流程分时票过了时间要能自动释放库存。所以读它的使用说明核心是按数据流转而不是按界面菜单去理解适合票务运营、运维工程师和后端开发者读前两者关心怎么调参和排障后者要盯住状态机的边界条件。2. 景区电子票务系统的核心模型库存、订单与核销的状态流转使用说明只会写界面但部署过这套系统的人都知道所有问题都出在数据模型上。先想清楚库存怎么扣、订单怎么流转后面配渠道、接闸机才有的放矢。2.1 门票库存为什么不能直接在 sku 上做减扣常见做法是在ticket_sku表里维护一个remaining字段窗口下单就UPDATE ticket_sku SET remaining remaining - 1。单机、单渠道的时候没问题一旦接入OTA、分销商、窗口多进程并发同一时刻的UPDATE会互相堵塞加了悲观锁又会让吞吐量直线下降。我一般会拆成两层ticket_sku只保存静态信息票种、价格、有效期另建stock_distribution表保存可用库存与已预占库存。分时票还要带上date和time_slot维度。预占库存不是直接扣减剩余量而是插入一条预占记录然后再做一次“预占量不能超过总量”的校验用数据库唯一索引或Redis原子操作去兜底。-- 分时库存表按票种日期时段唯一 CREATE TABLE stock_distribution ( id BIGINT PRIMARY KEY AUTO_INCREMENT, sku_id BIGINT NOT NULL, sale_date DATE NOT NULL, time_slot VARCHAR(16) NOT NULL DEFAULT ALL, total_qty INT NOT NULL COMMENT 可售总量, sold_qty INT NOT NULL DEFAULT 0, locked_qty INT NOT NULL DEFAULT 0 COMMENT 预占但未支付, UNIQUE KEY uk_sku_date_slot (sku_id, sale_date, time_slot) ) ENGINEInnoDB; -- 预占库存时先插入锁单记录再用行锁更新占比 BEGIN; SELECT id, total_qty, sold_qty, locked_qty FROM stock_distribution WHERE sku_id ? AND sale_date ? AND time_slot ? FOR UPDATE; UPDATE stock_distribution SET locked_qty locked_qty 1 WHERE id ? AND sold_qty locked_qty total_qty; COMMIT;这里的关键参数是sold_qty和locked_qty。sold_qty是已经支付并出票的数量locked_qty是用户下单但还没付款的预占数量。只有当sold_qty locked_qty小于total_qty时预占才允许成功。如果UPDATE影响行数为0就说明库存不足可以直接返回“已售罄”不需要再拼装业务错误码。为什么不让前端直接调用这个SQL因为Online渠道和窗口共用同一套库存必须把预占逻辑收敛到订单服务里。OTA渠道的订单还要走“先预占、后确认”的流程如果只做简单扣减第三方取消订单后库存就丢了。预占超时也要有定时回收机制扫描CREATE_TIME超过15分钟且未支付的预占记录把locked_qty减掉并释放订单。2.2 订单状态机从预占到过期要能回滚订单状态不是简单的created、paid、refunded三态。闸机核销、窗口退票、OTA取消、支付超时会让状态交叉。字段命名各家不同但状态至少要覆盖下面这张转换表当前状态触发动作下一状态库存处理PENDING用户支付成功PAIDlocked转soldPENDING支付超时/用户取消CANCELLED释放lockedPAID窗口取票/电子票下发ISSUED扣减soldISSUED闸机核销成功USED无PAY_REFUNDING退款发起REFUNDEDsold回滚PAY_REFUNDING闸机已核销REFUND_REJECTED不做库存回滚ISSUED分时票超过游玩日期EXPIRED按过期票规则处理这张表看起来简单真正容易出错的是退款和核销的竞争条件。游客在OTA申请退款同时人已经到闸机口验票两个请求几乎同时到达。如果订单服务先收到核销那退款必须被拒绝如果先收到退款请求但还没完成核销必须把订单状态改成“退款中被核销”由人工介入。解决思路是把订单状态机放在应用层用唯一版本号做乐观锁状态跃迁只允许从当前明确的状态流转到目标状态。# 使用 Redis 做核销防重的伪代码保证同一订单只被闸机成功处理一次 result redis.set( fticket:used:{ticket_no}, 1, nxTrue, ex86400 ) if result is None: raise TicketUsedAlready(该票已被核销) order order_repo.find_by_ticket(ticket_no) if order.status not in (OrderStatus.ISSUED, OrderStatus.PAID): raise OrderStateError(当前订单状态不可核销) order.status OrderStatus.USED order.used_at now() order.version 1 order_repo.update(order)这段代码前半段用SET NX完成防重后半段用版本号控制状态跃迁。注意不要只用数据库状态判断两个闸机并发打卡时read到相同状态再写回会把脏数据覆盖。有了Redis防重后到的请求直接抛错数据库里的version冲突反而成了最后一道防线。2.3 分时票与退改规则的边界景区电子票务系统和普通电商的另一个差异是票有强时间属性。上午票如果下午核销系统要不要放行这取决于票种配置但使用说明通常不会告诉你校验时间要用服务端时间不能用设备本地时间否则闸机的RTC漂移会让游客提前或延后入场。退改规则也要落在库存逻辑上。退票是否释放库存不是运营拍脑袋定的而是看订单是否已经出票。如果电子票已经下发到游客手机退票后必须生成作废列表并同步给闸机否则就会出现“库存释放了但门口还能验进”。要紧的配置项是退票截止时间、退款手续费比例和是否自动同步作废名单这些参数在部署时都要写入配置中心而不是塞在数据库的JSON字段里。3. 景区电子票务系统部署用 Docker Compose 拉起订单、库存与设备网关这一章讲怎么把系统跑起来。生产环境可能是K8s但本地验证和中小景区用Docker Compose就足够。先看服务怎么拆再决定容器怎么编排。3.1 服务拆成哪几块各自承担什么职责后端服务通常不是单体也不是微服务而是拆成五个有明确边界的模块服务模块核心职责依赖order-service下单、支付回调、订单状态机MySQL, Redisstock-service库存预占、释放、分时库存查询MySQL, Redisdevice-gateway闸机验票、设备心跳、黑名单下发Redis, order-serviceota-adapter对接美团、携程等渠道的订单推送与核销渠道开放接口report-worker对账、核销统计、延迟任务MySQL这五个模块可以合并成一个Java/Go服务打包部署但接口上必须保持独立。原因很简单节假日线上订单和线下核销的流量峰值不同分开部署才能单独扩device-gateway不用把订单服务整个复制一遍。设备网关只依赖Redis做防重和黑名单即使order-service短暂抖动闸机也能先放行后补状态。3.2 Docker Compose 最小部署MySQL、Redis、应用节点下面是本地验证用的docker-compose.yml去掉了监控和日志采集只保留能跑通卖票全流程的最小集合version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ticket_root MYSQL_DATABASE: scenic_ticket MYSQL_USER: ticket MYSQL_PASSWORD: ticket_pass ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci - --innodb_buffer_pool_size256M redis: image: redis:7-alpine ports: - 6379:6379 command: [redis-server, --appendonly, yes] order-service: image: scenic/order-service:latest environment: DB_DSN: ticket:ticket_passtcp(mysql:3306)/scenic_ticket?charsetutf8mb4 REDIS_ADDR: redis:6379 OTA_API_BASE: https://openapi.ota.example.com depends_on: - mysql - redis device-gateway: image: scenic/device-gateway:latest environment: REDIS_ADDR: redis:6379 ORDER_SERVICE_ADDR: order-service:8080 ports: - 9080:9080 depends_on: - redis - order-service关注device-gateway的ORDER_SERVICE_ADDR和redis配置这是闸机验票的直接依赖。MySQL的innodb_buffer_pool_size在小数据量下不需要设得很大但建议至少256M因为景区票务系统的库存表会短期产生大量行级锁活动。Redis开启appendonly是为了防重记录重启后不丢不过当天核销的票号TTL只有24小时丢失后即使重复核销也能靠数据库订单状态兜底。启动命令不复杂docker compose pull docker compose up -d等半分钟看docker compose psorder-service和device-gateway都应该处于healthy状态。如果订单服务容器反复重启多半是连不上MySQL先检查DB_DSN里的用户名密码和mysql容器是否在同一网络。也可以在宿主机上用docker compose logs order-service看具体连接错误避免空猜。3.3 基础配置渠道参数、闸机白名单与分时库存部署完成后第一件事不是上线卖票而是配置渠道和闸机。渠道配置在ota-adapter模块里核心字段是app_id、app_secret、回调地址和渠道票种映射表。回调地址必须能被渠道公网访问否则OTA下单后收不到确认通知。本地联调可以用内网穿透但生产环境一定要HTTPS签名验签用渠道方提供的公钥自己只保留私钥。闸机白名单配置要单独给一张表字段包括device_id、mac地址、加密密钥、状态。在线模式下设备每30秒上报心跳如果设备心跳超过3个周期未到运维后台要告警说明这个入口可能已经离线。离线时device-gateway会下发最近24小时的可用票号白名单到设备游客扫码后设备本地比对通过先放行等网络恢复再把核销记录上传。分时库存的参数建议在票种创建时一次配好露出给运营的只有三个每个时段总量、预占超时时间、过期票是否自动退款。预占超时时间设15分钟比较合适太短游客在支付页犹豫一下就被取消太长又会锁住库存影响黄金时段售票。系统使用说明里的“时段容量”说的就是stock_distribution里的total_qty这个值不是简单把全天票量除以时段数要按历史客流热力来分。4. 景区电子票务系统日常操作窗口、OTA验票、闸机与对账部署完了真实的工作从每天早上开园开始。这一章按操作顺序写窗口卖票、OTA渠道验票、闸机核销、下班前对账。4.1 窗口售票与手工出票的 API 调用顺序窗口终端不是直接在数据库里改订单而是通过下单接口完成。拿常见的HTTP接口举例一次窗口售票对应三次请求# 1. 预占库存并创建订单 curl -X POST http://order-service:8080/orders \ -H Content-Type: application/json \ -d { sku_id: 1001, sale_date: 2026-05-01, quantity: 2, customer: { id_type: ID_CARD, id_no: 110101199001011234 } } # 2. 窗口现金支付确认订单 curl -X POST http://order-service:8080/orders/20260501123456/confirm \ -H Content-Type: application/json \ -d {pay_method: CASH, cashier: CU-01} # 3. 取票并生成电子凭证 curl -X GET http://order-service:8080/orders/20260501123456/tickets第一个接口返回的order_no就是后续所有操作的主键。confirm接口会做两件事把PENDING订单推进到PAID并把预占库存转为已售库存。第三个接口预测到订单状态是PAID或ISSUED否则不会返回票号列表。窗口遇到的常见异常是游客取消支付却一直停留在支付页。这时不要直接删订单调取消接口触发库存释放或者等预占超时由后台回收。用手工在数据库删记录的代价是订单流水不完整财务对账时找不到支付记录。我一般让窗口收银员的终端上只展示“取消订单”按钮而不是数据库管理工具。4.2 闸机验票与离线降级在线核销和黑名单同步闸机模块在工作日的并发不高但节假日上午10点到11点会形成尖峰。设备网关收到闸机扫码请求后先查Redis里的核销防重键再查订单状态最后把核销结果写回。整个链路要控制在300ms以内所以订单状态不要实时查MySQL而是在出票时就写入Redis缓存闸机直接读缓存。离线降级的白名单机制是景区票务系统的保底方案。设备每隔固定间隔向device-gateway拉取“白名单批次”白名单里是未来48小时内已支付的票号和下单手机号脱敏信息。断网时闸机只用本机白名单做校验游客扫了票直接放行同时记录log。网络恢复后设备上传logorder-service把这些记录标记为USED。下面是白名单数据的简化结构device-gateway每次下发时都带上batch_id设备如果发现本地batch_id落后会主动请求全量同步{ batch_id: 20260501-1042, issued_at: 2026-05-01T10:42:0008:00, tickets: [ { ticket_no: T202605011234567, use_date: 2026-05-01, time_slot: MORNING, device_groups: [ENTRANCE_A, ENTRANCE_B] } ], blacklist: [ T202605011234599 ] }参数注意device_groups。这个字段决定该票允许从哪些入口通过比如南门入口设备只接受包含ENTRANCE_A的批次。如果配置为空表示所有闸机通用日常尽量不要为空否则黄牛会把单一入口的票拿到其他入口验给现场管理带来麻烦。在线与离线两种模式的能力差异可以直观对比能力在线模式离线降级模式验票依据Redis缓存订单服务本机白名单防重复核销Redis SET NX本地已核销列表状态回写实时写入MySQL断网期间延迟补传黑名单生效实时最近一次批次同步提示离线白名单下发要设置批次有效期设备每次开机先拉一次全量再按增量接口更新。如果漏了全量同步游客换了闸机入口后可能因为本地白名单不完整被拦在门外。4.3 OTA 对账脚本时间窗口、状态差异与自动补单OTA渠道的订单不是实时流动的往往每隔几分钟批量推送一次。对账脚本要解决的是“本地订单状态和渠道不一致”的问题。常见差异有三种本地已支付但渠道显示未支付、渠道已退款但本地仍未退、本地已核销但渠道没收到核销回传。我用Python写过一个最小对账脚本逻辑是拉取本地和渠道两个时间窗口的订单做集合比较import requests LOCAL_API http://order-service:8080/api/orders OTA_API http://ota-adapter:8080/api/channel/orders def fetch_orders(api, start, end): params {start: start, end: end, size: 1000} orders [] while True: resp requests.get(api, paramsparams, timeout30).json() orders.extend(resp[items]) if resp[next_cursor]: params[cursor] resp[next_cursor] else: break return {o[order_no]: o for o in orders} def diff_orders(local_start, local_end, ota_start, ota_end): local fetch_orders(LOCAL_API, local_start, local_end) ota fetch_orders(OTA_API, ota_start, ota_end) # 本地已支付渠道没有订单 for order_no, order in local.items(): if order[status] in (PAID, ISSUED) and order_no not in ota: yield local_not_synced, order_no # 渠道已退款本地还没退 for order_no, order in ota.items(): if order[status] REFUNDED and local.get(order_no, {}).get(status) PAID: yield refund_not_local, order_no for kind, order_no in diff_orders(2026-05-01T00:00:00, 2026-05-01T10:00:00, 2026-05-01T00:00:00, 2026-05-01T10:00:00): print(kind, order_no)这里的start和end建议用自然日对齐不要用滚动24小时否则退款日切会产生边界重复。local_not_synced的订单不要直接自动补单先看ota_adapter的推送日志判断是渠道还没推还是推了被签名验签拦截。refund_not_local的订单需要走退款接口但必须确认票没有核销核销过的只能走线下退现。对账时间建议选在凌晨2点到5点之间避开日切和退款高峰。脚本跑出来的差异写进对账差异表由值班人员逐条确认后再调接口全自动改单在票务场景里风险很大。5. 景区电子票务系统进阶用压测和 SQL 找出核销瓶颈闸机核销链路经常在节假日暴露出性能问题。上线前用ab或wrk压一下device-gateway的核销接口比什么都有效。注意压测要带Redis防重键别把同一张票并发打几百次测出来的全是预期内的重放。先构造一万张可用票号再并发压核销接口观察网关CPU和Redis连接数。ab -n 20000 -c 100 -p checkin.json -T application/json http://device-gateway:9080/checkin关注两个指标吞吐量TPS和P99延迟。TPS低于200、P99超过800ms就要查Redis连接池是否打满、网关到MySQL的连接是否复用。更常见的坑是每个核销请求都查一次订单服务拿订单信息代码写成同步HTTP调用会拖慢整个链路。把订单信息放Redis出票时写入核销只读缓存性能能上升一个数量级。闸机瓶颈之外库存预占也容易在购票高峰卡住。提前一天用SQL看分时库存的分布能预测哪个时段会爆SELECT sale_date, time_slot, SUM(total_qty) AS total, SUM(locked_qty) AS locked, SUM(sold_qty) AS sold, ROUND(SUM(locked_qty sold_qty) / SUM(total_qty) * 100, 1) AS occupancy FROM stock_distribution WHERE sale_date 2026-05-01 GROUP BY sale_date, time_slot ORDER BY occupancy DESC;occupancy超过85%的时段要提醒运营做限流或者临时调高该时段总量。这里的locked_qty高峰期常常虚高因为游客大批量下单但不支付。看到occupancy高不要直接加库存先看locked_qty占比如果其中大部分是超过5分钟的预占说明预占超时回收job没跑要查定时任务的执行日志。最后一个值得养成的习惯每次大促或节假日前把闸机验票的压测、分时库存的预占SQL、OTA对账差异表三个结果放到同一张值班表里。压测决定网关要不要扩容SQL决定票量是否调整对账决定前一天有没有遗留退款。这条检查顺序能覆盖景区电子票务系统上线后绝大部分事故来源。本文还有配套的精品资源点击获取 景区电子票务系统实战：状态一致性、库存模型与部署优化
简介这是一份面向景区票务管理人员、系统维护人员及信息化建设者的电子票务系统操作手册。文档以模块化方式梳理了售票、退票、基本信息与记录管理四大核心板块详细涵盖散客售票、导游卡与员工卡办理、会员卡注册补办续期、条码票登记、退票流程、设备信息维护、开发提示与显示屏信息、票种设置、散客票信息、导游卡信息、会员资料及各类记录查询等操作细节并配有异常处理与记录管理说明能帮助用户按流程快速掌握从购票到退票的全链路操作减少上线培训成本。资源包含1个doc格式文档压缩包大小12.48MB便于下载后直接查阅或打印。目前已有264人学习下载适合刚引入电子票务系统的中小景区或正在升级票务流程的运营团队参考使用。1. 景区电子票务系统使用说明真正的难点不在卖票而在状态一致性景区电子票务系统看着像一套常见的电商交易软件实际用起来最折磨人的不是下单支付而是线下设备与线上订单的状态对齐。游客在第三方平台买的电子票到闸机口扫码那一下系统要在几百毫秒内完成订单核验、防重复核销、票种匹配和状态回写这些动作一旦因为网络抖动或缓存失效卡住门口就会排起长队。这套系统管理的不只是订单而是库存、渠道、设备、财务四件事的联动窗口卖出去的票不能让 OTA 再卖同一张闸机已经核销的票不能进入退款流程分时票过了时间要能自动释放库存。所以读它的使用说明核心是按数据流转而不是按界面菜单去理解适合票务运营、运维工程师和后端开发者读前两者关心怎么调参和排障后者要盯住状态机的边界条件。2. 景区电子票务系统的核心模型库存、订单与核销的状态流转使用说明只会写界面但部署过这套系统的人都知道所有问题都出在数据模型上。先想清楚库存怎么扣、订单怎么流转后面配渠道、接闸机才有的放矢。2.1 门票库存为什么不能直接在 sku 上做减扣常见做法是在ticket_sku表里维护一个remaining字段窗口下单就UPDATE ticket_sku SET remaining remaining - 1。单机、单渠道的时候没问题一旦接入OTA、分销商、窗口多进程并发同一时刻的UPDATE会互相堵塞加了悲观锁又会让吞吐量直线下降。我一般会拆成两层ticket_sku只保存静态信息票种、价格、有效期另建stock_distribution表保存可用库存与已预占库存。分时票还要带上date和time_slot维度。预占库存不是直接扣减剩余量而是插入一条预占记录然后再做一次“预占量不能超过总量”的校验用数据库唯一索引或Redis原子操作去兜底。-- 分时库存表按票种日期时段唯一 CREATE TABLE stock_distribution ( id BIGINT PRIMARY KEY AUTO_INCREMENT, sku_id BIGINT NOT NULL, sale_date DATE NOT NULL, time_slot VARCHAR(16) NOT NULL DEFAULT ALL, total_qty INT NOT NULL COMMENT 可售总量, sold_qty INT NOT NULL DEFAULT 0, locked_qty INT NOT NULL DEFAULT 0 COMMENT 预占但未支付, UNIQUE KEY uk_sku_date_slot (sku_id, sale_date, time_slot) ) ENGINEInnoDB; -- 预占库存时先插入锁单记录再用行锁更新占比 BEGIN; SELECT id, total_qty, sold_qty, locked_qty FROM stock_distribution WHERE sku_id ? AND sale_date ? AND time_slot ? FOR UPDATE; UPDATE stock_distribution SET locked_qty locked_qty 1 WHERE id ? AND sold_qty locked_qty total_qty; COMMIT;这里的关键参数是sold_qty和locked_qty。sold_qty是已经支付并出票的数量locked_qty是用户下单但还没付款的预占数量。只有当sold_qty locked_qty小于total_qty时预占才允许成功。如果UPDATE影响行数为0就说明库存不足可以直接返回“已售罄”不需要再拼装业务错误码。为什么不让前端直接调用这个SQL因为Online渠道和窗口共用同一套库存必须把预占逻辑收敛到订单服务里。OTA渠道的订单还要走“先预占、后确认”的流程如果只做简单扣减第三方取消订单后库存就丢了。预占超时也要有定时回收机制扫描CREATE_TIME超过15分钟且未支付的预占记录把locked_qty减掉并释放订单。2.2 订单状态机从预占到过期要能回滚订单状态不是简单的created、paid、refunded三态。闸机核销、窗口退票、OTA取消、支付超时会让状态交叉。字段命名各家不同但状态至少要覆盖下面这张转换表当前状态触发动作下一状态库存处理PENDING用户支付成功PAIDlocked转soldPENDING支付超时/用户取消CANCELLED释放lockedPAID窗口取票/电子票下发ISSUED扣减soldISSUED闸机核销成功USED无PAY_REFUNDING退款发起REFUNDEDsold回滚PAY_REFUNDING闸机已核销REFUND_REJECTED不做库存回滚ISSUED分时票超过游玩日期EXPIRED按过期票规则处理这张表看起来简单真正容易出错的是退款和核销的竞争条件。游客在OTA申请退款同时人已经到闸机口验票两个请求几乎同时到达。如果订单服务先收到核销那退款必须被拒绝如果先收到退款请求但还没完成核销必须把订单状态改成“退款中被核销”由人工介入。解决思路是把订单状态机放在应用层用唯一版本号做乐观锁状态跃迁只允许从当前明确的状态流转到目标状态。# 使用 Redis 做核销防重的伪代码保证同一订单只被闸机成功处理一次 result redis.set( fticket:used:{ticket_no}, 1, nxTrue, ex86400 ) if result is None: raise TicketUsedAlready(该票已被核销) order order_repo.find_by_ticket(ticket_no) if order.status not in (OrderStatus.ISSUED, OrderStatus.PAID): raise OrderStateError(当前订单状态不可核销) order.status OrderStatus.USED order.used_at now() order.version 1 order_repo.update(order)这段代码前半段用SET NX完成防重后半段用版本号控制状态跃迁。注意不要只用数据库状态判断两个闸机并发打卡时read到相同状态再写回会把脏数据覆盖。有了Redis防重后到的请求直接抛错数据库里的version冲突反而成了最后一道防线。2.3 分时票与退改规则的边界景区电子票务系统和普通电商的另一个差异是票有强时间属性。上午票如果下午核销系统要不要放行这取决于票种配置但使用说明通常不会告诉你校验时间要用服务端时间不能用设备本地时间否则闸机的RTC漂移会让游客提前或延后入场。退改规则也要落在库存逻辑上。退票是否释放库存不是运营拍脑袋定的而是看订单是否已经出票。如果电子票已经下发到游客手机退票后必须生成作废列表并同步给闸机否则就会出现“库存释放了但门口还能验进”。要紧的配置项是退票截止时间、退款手续费比例和是否自动同步作废名单这些参数在部署时都要写入配置中心而不是塞在数据库的JSON字段里。3. 景区电子票务系统部署用 Docker Compose 拉起订单、库存与设备网关这一章讲怎么把系统跑起来。生产环境可能是K8s但本地验证和中小景区用Docker Compose就足够。先看服务怎么拆再决定容器怎么编排。3.1 服务拆成哪几块各自承担什么职责后端服务通常不是单体也不是微服务而是拆成五个有明确边界的模块服务模块核心职责依赖order-service下单、支付回调、订单状态机MySQL, Redisstock-service库存预占、释放、分时库存查询MySQL, Redisdevice-gateway闸机验票、设备心跳、黑名单下发Redis, order-serviceota-adapter对接美团、携程等渠道的订单推送与核销渠道开放接口report-worker对账、核销统计、延迟任务MySQL这五个模块可以合并成一个Java/Go服务打包部署但接口上必须保持独立。原因很简单节假日线上订单和线下核销的流量峰值不同分开部署才能单独扩device-gateway不用把订单服务整个复制一遍。设备网关只依赖Redis做防重和黑名单即使order-service短暂抖动闸机也能先放行后补状态。3.2 Docker Compose 最小部署MySQL、Redis、应用节点下面是本地验证用的docker-compose.yml去掉了监控和日志采集只保留能跑通卖票全流程的最小集合version: 3.8 services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: ticket_root MYSQL_DATABASE: scenic_ticket MYSQL_USER: ticket MYSQL_PASSWORD: ticket_pass ports: - 3306:3306 volumes: - mysql_data:/var/lib/mysql command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci - --innodb_buffer_pool_size256M redis: image: redis:7-alpine ports: - 6379:6379 command: [redis-server, --appendonly, yes] order-service: image: scenic/order-service:latest environment: DB_DSN: ticket:ticket_passtcp(mysql:3306)/scenic_ticket?charsetutf8mb4 REDIS_ADDR: redis:6379 OTA_API_BASE: https://openapi.ota.example.com depends_on: - mysql - redis device-gateway: image: scenic/device-gateway:latest environment: REDIS_ADDR: redis:6379 ORDER_SERVICE_ADDR: order-service:8080 ports: - 9080:9080 depends_on: - redis - order-service关注device-gateway的ORDER_SERVICE_ADDR和redis配置这是闸机验票的直接依赖。MySQL的innodb_buffer_pool_size在小数据量下不需要设得很大但建议至少256M因为景区票务系统的库存表会短期产生大量行级锁活动。Redis开启appendonly是为了防重记录重启后不丢不过当天核销的票号TTL只有24小时丢失后即使重复核销也能靠数据库订单状态兜底。启动命令不复杂docker compose pull docker compose up -d等半分钟看docker compose psorder-service和device-gateway都应该处于healthy状态。如果订单服务容器反复重启多半是连不上MySQL先检查DB_DSN里的用户名密码和mysql容器是否在同一网络。也可以在宿主机上用docker compose logs order-service看具体连接错误避免空猜。3.3 基础配置渠道参数、闸机白名单与分时库存部署完成后第一件事不是上线卖票而是配置渠道和闸机。渠道配置在ota-adapter模块里核心字段是app_id、app_secret、回调地址和渠道票种映射表。回调地址必须能被渠道公网访问否则OTA下单后收不到确认通知。本地联调可以用内网穿透但生产环境一定要HTTPS签名验签用渠道方提供的公钥自己只保留私钥。闸机白名单配置要单独给一张表字段包括device_id、mac地址、加密密钥、状态。在线模式下设备每30秒上报心跳如果设备心跳超过3个周期未到运维后台要告警说明这个入口可能已经离线。离线时device-gateway会下发最近24小时的可用票号白名单到设备游客扫码后设备本地比对通过先放行等网络恢复再把核销记录上传。分时库存的参数建议在票种创建时一次配好露出给运营的只有三个每个时段总量、预占超时时间、过期票是否自动退款。预占超时时间设15分钟比较合适太短游客在支付页犹豫一下就被取消太长又会锁住库存影响黄金时段售票。系统使用说明里的“时段容量”说的就是stock_distribution里的total_qty这个值不是简单把全天票量除以时段数要按历史客流热力来分。4. 景区电子票务系统日常操作窗口、OTA验票、闸机与对账部署完了真实的工作从每天早上开园开始。这一章按操作顺序写窗口卖票、OTA渠道验票、闸机核销、下班前对账。4.1 窗口售票与手工出票的 API 调用顺序窗口终端不是直接在数据库里改订单而是通过下单接口完成。拿常见的HTTP接口举例一次窗口售票对应三次请求# 1. 预占库存并创建订单 curl -X POST http://order-service:8080/orders \ -H Content-Type: application/json \ -d { sku_id: 1001, sale_date: 2026-05-01, quantity: 2, customer: { id_type: ID_CARD, id_no: 110101199001011234 } } # 2. 窗口现金支付确认订单 curl -X POST http://order-service:8080/orders/20260501123456/confirm \ -H Content-Type: application/json \ -d {pay_method: CASH, cashier: CU-01} # 3. 取票并生成电子凭证 curl -X GET http://order-service:8080/orders/20260501123456/tickets第一个接口返回的order_no就是后续所有操作的主键。confirm接口会做两件事把PENDING订单推进到PAID并把预占库存转为已售库存。第三个接口预测到订单状态是PAID或ISSUED否则不会返回票号列表。窗口遇到的常见异常是游客取消支付却一直停留在支付页。这时不要直接删订单调取消接口触发库存释放或者等预占超时由后台回收。用手工在数据库删记录的代价是订单流水不完整财务对账时找不到支付记录。我一般让窗口收银员的终端上只展示“取消订单”按钮而不是数据库管理工具。4.2 闸机验票与离线降级在线核销和黑名单同步闸机模块在工作日的并发不高但节假日上午10点到11点会形成尖峰。设备网关收到闸机扫码请求后先查Redis里的核销防重键再查订单状态最后把核销结果写回。整个链路要控制在300ms以内所以订单状态不要实时查MySQL而是在出票时就写入Redis缓存闸机直接读缓存。离线降级的白名单机制是景区票务系统的保底方案。设备每隔固定间隔向device-gateway拉取“白名单批次”白名单里是未来48小时内已支付的票号和下单手机号脱敏信息。断网时闸机只用本机白名单做校验游客扫了票直接放行同时记录log。网络恢复后设备上传logorder-service把这些记录标记为USED。下面是白名单数据的简化结构device-gateway每次下发时都带上batch_id设备如果发现本地batch_id落后会主动请求全量同步{ batch_id: 20260501-1042, issued_at: 2026-05-01T10:42:0008:00, tickets: [ { ticket_no: T202605011234567, use_date: 2026-05-01, time_slot: MORNING, device_groups: [ENTRANCE_A, ENTRANCE_B] } ], blacklist: [ T202605011234599 ] }参数注意device_groups。这个字段决定该票允许从哪些入口通过比如南门入口设备只接受包含ENTRANCE_A的批次。如果配置为空表示所有闸机通用日常尽量不要为空否则黄牛会把单一入口的票拿到其他入口验给现场管理带来麻烦。在线与离线两种模式的能力差异可以直观对比能力在线模式离线降级模式验票依据Redis缓存订单服务本机白名单防重复核销Redis SET NX本地已核销列表状态回写实时写入MySQL断网期间延迟补传黑名单生效实时最近一次批次同步提示离线白名单下发要设置批次有效期设备每次开机先拉一次全量再按增量接口更新。如果漏了全量同步游客换了闸机入口后可能因为本地白名单不完整被拦在门外。4.3 OTA 对账脚本时间窗口、状态差异与自动补单OTA渠道的订单不是实时流动的往往每隔几分钟批量推送一次。对账脚本要解决的是“本地订单状态和渠道不一致”的问题。常见差异有三种本地已支付但渠道显示未支付、渠道已退款但本地仍未退、本地已核销但渠道没收到核销回传。我用Python写过一个最小对账脚本逻辑是拉取本地和渠道两个时间窗口的订单做集合比较import requests LOCAL_API http://order-service:8080/api/orders OTA_API http://ota-adapter:8080/api/channel/orders def fetch_orders(api, start, end): params {start: start, end: end, size: 1000} orders [] while True: resp requests.get(api, paramsparams, timeout30).json() orders.extend(resp[items]) if resp[next_cursor]: params[cursor] resp[next_cursor] else: break return {o[order_no]: o for o in orders} def diff_orders(local_start, local_end, ota_start, ota_end): local fetch_orders(LOCAL_API, local_start, local_end) ota fetch_orders(OTA_API, ota_start, ota_end) # 本地已支付渠道没有订单 for order_no, order in local.items(): if order[status] in (PAID, ISSUED) and order_no not in ota: yield local_not_synced, order_no # 渠道已退款本地还没退 for order_no, order in ota.items(): if order[status] REFUNDED and local.get(order_no, {}).get(status) PAID: yield refund_not_local, order_no for kind, order_no in diff_orders(2026-05-01T00:00:00, 2026-05-01T10:00:00, 2026-05-01T00:00:00, 2026-05-01T10:00:00): print(kind, order_no)这里的start和end建议用自然日对齐不要用滚动24小时否则退款日切会产生边界重复。local_not_synced的订单不要直接自动补单先看ota_adapter的推送日志判断是渠道还没推还是推了被签名验签拦截。refund_not_local的订单需要走退款接口但必须确认票没有核销核销过的只能走线下退现。对账时间建议选在凌晨2点到5点之间避开日切和退款高峰。脚本跑出来的差异写进对账差异表由值班人员逐条确认后再调接口全自动改单在票务场景里风险很大。5. 景区电子票务系统进阶用压测和 SQL 找出核销瓶颈闸机核销链路经常在节假日暴露出性能问题。上线前用ab或wrk压一下device-gateway的核销接口比什么都有效。注意压测要带Redis防重键别把同一张票并发打几百次测出来的全是预期内的重放。先构造一万张可用票号再并发压核销接口观察网关CPU和Redis连接数。ab -n 20000 -c 100 -p checkin.json -T application/json http://device-gateway:9080/checkin关注两个指标吞吐量TPS和P99延迟。TPS低于200、P99超过800ms就要查Redis连接池是否打满、网关到MySQL的连接是否复用。更常见的坑是每个核销请求都查一次订单服务拿订单信息代码写成同步HTTP调用会拖慢整个链路。把订单信息放Redis出票时写入核销只读缓存性能能上升一个数量级。闸机瓶颈之外库存预占也容易在购票高峰卡住。提前一天用SQL看分时库存的分布能预测哪个时段会爆SELECT sale_date, time_slot, SUM(total_qty) AS total, SUM(locked_qty) AS locked, SUM(sold_qty) AS sold, ROUND(SUM(locked_qty sold_qty) / SUM(total_qty) * 100, 1) AS occupancy FROM stock_distribution WHERE sale_date 2026-05-01 GROUP BY sale_date, time_slot ORDER BY occupancy DESC;occupancy超过85%的时段要提醒运营做限流或者临时调高该时段总量。这里的locked_qty高峰期常常虚高因为游客大批量下单但不支付。看到occupancy高不要直接加库存先看locked_qty占比如果其中大部分是超过5分钟的预占说明预占超时回收job没跑要查定时任务的执行日志。最后一个值得养成的习惯每次大促或节假日前把闸机验票的压测、分时库存的预占SQL、OTA对账差异表三个结果放到同一张值班表里。压测决定网关要不要扩容SQL决定票量是否调整对账决定前一天有没有遗留退款。这条检查顺序能覆盖景区电子票务系统上线后绝大部分事故来源。本文还有配套的精品资源点击获取