企业官网建设流程全解析

国庆期间全国景区集体限流。借九寨沟（4.1 万人次/天、32 通道 1.9 万人次/小时）和都江堰（达阈值停线上售票）两个公开案例，把大客流票务系统的三个核心设计拆开讲清楚：阈值怎么定、核销怎么扛、库存怎么不超售。

一、先纠一个常见的定阈值错误

做票务系统，第一件事是把"能卖多少票"定下来。很多项目的做法是拿通道通行能力倒推：32 个通道，每小时 1.9 万人次，那高峰时段多开通道不就行了？

这个推导错在把两个不同的约束当成了一个。

• 承载量= 安全/生态/体验/应急四项承载的最小值，它回答"今天能放多少人进来"；
• 通道吞吐= 设备与链路的执行能力，它回答"这些人在单位时间内能不能顺畅送进去"。

九寨沟把旺季承载量定在 4.1 万人次/天，而通道吞吐是 1.9 万人次/小时——两个数字不是一个量级，因为它们本来就不是一回事。如果按吞吐倒推票量，一天能放进几十万人，安全红线早就失守了。

正确做法：先按承载量定票池上限（4.1 万），再用通道吞吐验证"这个量能不能在营业时间内顺畅送进去"（32 通道 × 1.9 万/小时，明显够用，还留有余量），最后用真实运行数据校准（九寨沟"五一"连续三天跑到 4.1 万，排队 ≤15 分钟、满意度 ≥95%，阈值被验证成立）。

限流阈值由承载量决定，不是由通道吞吐决定——把两本账混在一起算，节假日当天一定出事。

二、核销链路：峰值不是靠"多开闸机"兑现的

定好票量，下一个瓶颈是核销。1.9 万人次/小时、32 通道，平均每通道约 594 人次/小时，折合每人不到 6 秒——这 6 秒里要完成识别、校验、开闸、异常拦截。

要做到这一点，链路设计上有三个硬要求：

1. 核销不能强依赖实时联网。

高峰期每秒几十到上百次核销请求打到中心服务，任何一个环节（网关、鉴权、库存服务）抖动都会让队伍堆积。成熟做法是票证在本地留存副本，核销在闸机侧闭环，网络只做事后同步。

2. 通道按规则分流，而不是"来一个检一个"。

团队票、散客、年卡、优惠票的校验逻辑不同。混在一个通道，一次人工核验就会拖慢整条队。分通道、分规则，才能把理论吞吐跑成实际吞吐。

3. 动线要提前算。

入口吞吐再高，如果游客进来卡在观光车站，压力只是从"入口"转移到"站台"。九寨沟智慧管理中心用弧形大屏实时调度发车频次，本质是把"入口吞吐"和"内部运力"联起来算——这是系统边界的问题，不是单个闸机的问题。

三、候补与库存释放：难点在并发安全，不在排队

节假日票卖完后，真正棘手的是"退订和爽约释放出来的票，怎么公平、安全地再分配"。九寨沟的做法是两套机制并行：

• 候补预订：达承载量后开启候补登记，退订按候补顺序依次分配，未成功原路退款；
• 定时释放：退票统一回流库存池，每天 08:00 和 17:00 集中释放。

从系统实现看，这两套机制的技术难点不是"排队"，而是"库存池的并发安全"。

候补系统的难点不是排队，而是库存池的并发安全。

一个典型的错误实现是：`退订 → 减库存 → 通知候补用户 → 候补用户下单`。这个串行链条里任何一步失败，都会产生两种事故：

• "有票下不了单"：库存显示有，但订单创建时库存已被别人拿走；
• "一票两卖"（超售）：同一个退订票被多个候补用户同时锁定。

正确做法：库存释放必须是原子操作——用数据库行锁/乐观锁 + 幂等去重，把"扣减库存"和"生成订单"放进同一个事务；候补分配用有序队列 + 幂等 token，保证"一张退订票只分配给一个候补用户"。释放失败的票要能回滚回库存池，而不是丢失。

四、降级销售：都江堰模式的工程含义

比"售罄"更考验系统的是"人还在来，但入园已达阈值"。都江堰/青城山（前山）10 月 3 日的处理是个范本：

截至 10 月 3 日 10 时 39 分，游客量达到暂停入园人数，景区停止线上售票并启动动态管控，仅保留窗口、扫码购、自助机等渠道销售当日门票，按现场人数实时调控入园。

在系统层面，这叫降级销售，关键点是"停线上、保现场"：

• 线上停售：避免远端继续把游客吸引过来（信息不对称是最大的体验杀手）；
• 现场保留：窗口/自助机/扫码购按现场容量继续放行当日票，给在途游客缓冲；
• 动态阈值：阈值不是死数字，随现场人数滚动调整。

它的架构意义是把"安全责任"和"销售冲动"解耦：售票系统可以随时停线上，但现场设备仍按安全阈值工作，不会因为一次售罄就整体瘫痪。

五、断网续售：大客流系统的隐性门槛

前面都假设网络正常。但山区景区旺季网络抖动几乎必然，如果核销强依赖联网，一次抖动就能让入口停摆。所以大客流系统必须有离线能力：

• 票证本地化：已售票在闸机侧留副本，断网时照常核销；
• 库存预扣：断网期间售票走本地库存，恢复后自动对账同步；
• 冲突兜底：恢复后若发现超卖，要有明确补偿规则（写进合同与验收）。

六、给需求书和验收的 5 个技术问题

选型或验收一套大客流票务系统时，下面 5 个问题比"有多少功能模块"更能筛出真做过大客流的供应商：

1. 限流阈值怎么来的？是否基于承载量四项最小值 + 真实运行数据校准？

2. 核销链路是本地闭环还是实时联网？峰值 QPS 是多少、压测过吗？

3. 候补的库存释放是否原子？会不会"有票下不了单"或"一票两卖"？

4. 有没有降级销售？达阈值时能否只停线上、保留现场并按现场人数调控？

5. 断网怎么办？离线核销、本地库存预扣、恢复后对账与超卖补偿，合同写清楚了吗？

大客流的系统不是"扛"住的，是"算"出来的。

这是《景区票务实战》系列的第 2 篇。下一篇 #03 拆"断网了怎么检票"：离线核销、本地库存预扣、恢复后对账与超卖补偿的完整实现。关注不迷路。

*（本文数据来源：九寨沟景区管理局官方发布、2026-10-03 中国新闻网、2026-10-04 央视新闻/21 经济网等公开报道；技术判断基于票务系统设计与落地经验，具体项目数据已脱敏。）*