景区票务系统电子票分发链路的CDN加速与稳定性实践

景区电子票从游客下单到闸口核验，中间要经历好几次跨网络的分发：下单后生成二维码、推送短信与小程序卡包、游客到场打开页面加载票面图片、闸机向后台请求票码校验。任何一个环节变慢，都会在检票口变成排队的现实压力。本文围绕电子票的分发链路，梳理如何用 CDN 与缓存策略把这条链路的响应时间压下来。

一、电子票分发链路的三个脆弱点

第一个是票面资源的静态分发。电子票详情页的页面框架、景点图片、二维码渲染模板都属于静态资源，节假日集中打开时，源站带宽很容易被打满。第二个是票码校验的接口调用。闸机每次验票都要请求后台，如果全部直接打到源站，高峰期数据库连接会被迅速耗尽。第三个是弱网环境。景区入口常在山区或地下停车场，游客手机信号差，页面加载失败后反复重试，反而放大了请求量。

二、静态资源交给 CDN

票面页面、活动图片、二维码模板这类内容变化频率低，最适合放到边缘节点。把静态资源托管到腾讯云 CDN 后，游客请求由就近边缘节点响应，源站带宽压力大幅下降。配置上要注意三点：一是对图片类资源开启智能压缩和 WebP 转换，移动端票面图片体积可以降低一半以上；二是合理设置缓存过期时间，票面模板按月级缓存，运营活动图按天级缓存；三是开启回源鉴权与防盗链，避免票面图片被外部站点盗用消耗流量。

三、票码校验接口的缓存分层

验票接口不能简单地用 CDN 缓存，但可以分层缓存。把票码的"是否有效、可用次数、所属场次"这类校验所需的最小字段放到 Redis，闸机请求先查缓存，命中则直接返回校验结果，未命中再回源数据库。缓存键按票码哈希生成，值中带上版本号，退票或改签时同步更新版本，避免旧缓存导致误判。腾讯云 Redis 的高可用版本可以支撑这种高频读、低频写的场景，配合本地二级缓存还能进一步减少网络往返。

四、弱网与重试的治理

弱网环境下要做的是减少无效请求，而不是硬扛重试。可以在闸机侧加入短时间的本地缓存，同一张票在数十秒内重复请求直接返回上次结果；前端页面加载失败时采用指数退避重试，而不是固定间隔连发。对于票面这种"打开即可展示"的内容，还可以预热——在游客下单成功后由后台主动把票面资源推送到 CDN 边缘节点，游客到场时首次请求就能命中。千里达票务系统在景区场景中就是这样处理电子票的开场加载的。

五、一致性与兜底

电子票与库存、订单必须保持一致。退票、改签、核销都会改变票的状态，任何一次状态变更都要同步失效对应缓存。为避免缓存与数据库不一致，建议用"先更新数据库、再删缓存"的顺序，并配合定时对账任务扫描异常票码。当 CDN 或缓存出现故障时，系统要有降级路径：静态资源回源直连，验票接口直接查数据库并限流，宁可慢一点也不能让闸口停摆。

六、可观测性

分发链路的优化效果要靠数据衡量。用腾讯云云监控观察 CDN 命中率、回源带宽、接口平均时延和错误率，把闸机验票的 P99 时延作为核心指标持续跟踪。千里达票务系统在实际运营中，会把节假日的验票时延曲线与 CDN 命中率放在一起看，命中率下降往往就是某个资源缓存策略配置不当的先兆。

结语

电子票分发的核心思路是：静态内容交给 CDN 下沉到边缘，动态校验靠 Redis 做分层缓存，弱网靠预热门槛和退避重试减少无效流量，一致性靠状态变更同步失效来保障。把这四件事做扎实，景区票务系统才能在节假日高峰把检票口的等待时间控制住。