基于腾讯云构建景区票务系统实时客流统计架构

一、景区客流统计为什么要实时

在景区运营中，客流数据是做调度决策的核心依据。传统模式下，景区管理者往往第二天才能看到前一天的入园数据，等发现某个区域拥堵时，游客已经排起长队。

我们在做景区票务系统时，把"实时客流统计"作为核心能力来建设。理想状态是：游客扫码入园的瞬间，大屏上的客流数字就更新，管理者能看到当前在园人数、各区域分布、同比环比。本文分享基于腾讯云产品实现这套实时统计架构的经验。

二、数据从哪来：埋点与事件流

景区里能产生客流数据的节点很多：

• 入口闸机：每刷一次票就是一条入园事件；
• 出口闸机：每条是离园事件；
• 内部点位：索道上下站、观光车站点、热门打卡点的红外计数器；
• 二次消费：餐饮、零售点的消费记录，可辅助判断停留时长。

在千里达票务系统的架构里，所有这些事件统一走一条消息通道，不分散到各个业务库。

三、架构设计：采集→队列→计算→存储→展示

1. 采集层：边缘端上报

闸机、手持机、红外计数器等设备通过HTTP接口上报事件到接入网关。接入网关用腾讯云CLB做负载均衡，后端挂多台采集服务实例。

关键点：采集服务不做重逻辑，只做校验和转发，保证入口吞吐。单台实例每秒可处理上千条事件。

2. 消息层：TDMQ削峰

事件上报后不直接写数据库，而是发到腾讯云TDMQ消息队列。为什么用消息队列？

• 黄金周峰值事件量是平日的5-10倍，直接写库会打满CDB连接；
• 下游统计服务、大屏服务、告警服务各自消费，互不影响；
• 消费失败可重试，事件不丢。

Topic按事件类型分区：入园、出园、点位客流、消费记录各一个分区，消费者按分区并行处理。

3. 计算层：实时聚合

统计服务订阅TDMQ消息，实时做聚合计算：

• 在园人数 = 累计入园 - 累计出园，Redis维护这个计数；
• 各点位人数按5分钟窗口聚合，结果写Redis和CDB；
• 同比环比按小时预计算，供大屏和报表使用。

用腾讯云Redis做实时计数，因为Redis单线程O(1)增减，适合这种高频写、高频读的场景。

4. 存储层：CDB + Redis分层

• Redis：存实时在园人数、当前小时点位分布，供大屏秒级刷新；
• CDB云数据库MySQL：存5分钟粒度的历史聚合数据，供日报、周报、趋势分析；
• COS：原始事件日志归档，保留3个月，供事后审计和复盘。

5. 展示层：大屏与API

• 景区指挥大屏：WebSocket推流，3秒刷新一次；
• 管理后台API：供运营人员查询任意时段客流；
• 告警服务：在园人数超过阈值时自动推送企业微信。

四、几个关键问题的处理

1. 设备离线事件怎么办

景区里闸机网络偶尔抖动，设备会本地缓存事件，恢复后批量补传。统计服务做了幂等处理，同一条事件重复上报只算一次，避免重复计数。

2. 时钟不同步怎么办

各设备时钟可能有偏差。我们以服务端收到事件的时间为准做聚合，而不是设备上报的时间戳，避免时序混乱。

3. 数据延迟怎么监控

在腾讯云云监控上配置了TDMQ消息堆积量告警。如果消费速度跟不上生产速度（比如某条消费者挂了），堆积量上升就告警，运维人员及时介入。正常情况下事件从产生到大屏展示延迟在3秒以内。

五、落地效果

这套实时客流统计架构在千里达票务系统中跑下来：

• 大屏刷新延迟控制在3秒内，管理者看到的就是实时数据；
• 黄金周峰值每秒处理2000+条事件，CDB压力不到平时的20%；
• 客流超阈值自动告警，景区提前疏导，拥堵投诉明显下降；
• 历史数据可追溯，运营复盘有数据依据。

六、总结

景区票务系统的实时客流统计，核心不是"建个大屏"，而是背后的事件流架构：用消息队列解耦采集和计算，用Redis扛实时计数，用CDB存历史数据，用云监控保障链路可观测。腾讯云的产品组合刚好覆盖了这条链路的每个环节，团队可以把精力放在业务逻辑上，而不是自己搭消息中间件和监控系统。