中科智旅千里达票务系统：基于腾讯云CDB与Redis实现分时预约高并发架构

一、分时预约：智慧景区的刚需能力

自从文旅部推行景区限流政策以来，分时预约已经成为5A/4A景区的标配能力。但在实际落地中，我们在千里达票务系统的多个景区项目中发现，分时预约的技术难点不在于"做个预约表单"，而在于高峰时段的并发预约能力：

• 热门景区暑期预约通道开放瞬间，上万用户同时抢约某个时段；
• 每个时段有严格的人数上限，超约会导致现场拥挤；
• 预约成功后还要和售票、检票、客流统计联动；
• 黄牛脚本批量刷约，正常用户约不到。

本文分享千里达票务系统基于腾讯云CDB（云数据库MySQL）和云Redis构建分时预约高并发架构的实践经验。

二、为什么不能直接用数据库扛

最早版本的分时预约，我们直接用数据库事务扣减时段库存：开启事务后查询剩余名额并加行锁，扣减库存，插入预约记录，最后提交事务。

这个方案在平日没问题，但黄金周放票时直接崩了：

• 行锁竞争激烈，事务排队，P99延迟飙到数秒；
• 数据库连接池被打满，其他业务查询受影响；
• 高峰时QPS不过千，远不够用。

结论很明确：库存扣减这种高频操作，必须放到Redis里做，数据库只做持久化。

三、基于腾讯云Redis的分时预约核心设计

1. 时段库存预热到Redis

每天凌晨，定时任务把次日所有可预约时段的库存预热到腾讯云Redis，key格式为 qld:slot:日期:时段ID，value为剩余名额数字。

选择腾讯云Redis集群版的原因：

• 集群版支持10万+ QPS，足够应对高峰；
• 主从自动切换，SLA 99.95%，缓存层不成为单点；
• 支持Lua脚本，保证"查库存+扣减"原子性。

2. Lua脚本原子扣减

用户预约时，执行Redis Lua脚本：先取出当前库存，判断大于0则原子减一并返回成功，否则返回已约满。整个"判断+扣减"在Redis单线程内完成，不会出现并发超卖。实测单节点可支撑每秒数千次预约扣减。

3. 异步落库到腾讯云CDB

Redis扣减成功后，预约记录不直接写数据库，而是发到腾讯云TDMQ消息队列，由消费者异步写入CDB：

• 用户端立即返回"预约成功"，体验快；
• 数据库压力被消息队列削峰填谷；
• 消费失败自动重试，保证不丢数据。

四、防刷与公平性设计

1. 一人约一次：Redis去重

为了防止一个人重复约同一个时段，用Redis Set做去重。预约前先判断用户ID是否在已预约集合中，已约过直接拒绝。Set操作O(1)，性能无忧。

2. 滑动窗口限流

对单个IP/设备ID做滑动窗口限流，用Redis ZSet实现：1分钟内同一IP最多请求10次预约接口，超出直接返回429，拦截脚本批量刷约。

3. 验证码前置

对预约接口加腾讯云验证码（CAPTCHA），人机验证通过后才允许提交，进一步挡掉自动化脚本。

五、数据一致性保障

Redis和数据库之间如何保证一致？我们做了几层兜底：

1. 每日对账：凌晨定时任务对比Redis库存和CDB预约记录，差异自动修正；
2. 补偿队列：异步写库失败的记录进死信队列，人工或自动补偿；
3. 库存回补：用户取消预约时，Redis库存加一，同时发消息异步更新数据库；
4. 只读校验：查询预约记录以CDB为准，Redis只做写路径加速。

六、落地效果

这套架构在千里达票务系统中支撑了多个山岳型景区的分时预约场景：

• 预约接口P99延迟从800ms降到50ms以内；
• 单时段高峰QPS支撑到5000+，数据库零压力；
• 黄金周零超约、零库存不一致事故；
• 黄牛脚本刷约成功率下降90%以上。

七、总结

千里达票务系统的分时预约高并发方案，核心思路是：热数据放Redis做原子扣减，持久化交给CDB，消息队列削峰填谷，多层防刷保证公平。腾讯云Redis集群版扛住了高峰并发，CDB承担最终一致性存储，TDMQ解耦异步流程。这套模式不局限于景区预约，但凡涉及"限量抢购、分时段配额"的业务场景都可以复用。

后续计划接入腾讯云TI平台做客流预测，提前预判热门时段，引导用户错峰预约。