国庆天安门景区验票系统-支持每天10亿人次的高并发验票解决方案
设计一个支持国庆期间每天 10 亿人次的景区验票系统，核心挑战在于高并发处理（峰值可能达每秒数十万请求）、高可用（零故障容忍）、低延迟（验票响应需 < 500ms）以及数据一致性（防止重复验票 / 假票）。
以下是具体设计思路：
一、核心需求拆解
1. 流量规模：日均 10 亿人次 → 平均每秒约 1.15 万请求，峰值（如上午 9-11 点）可能达每秒 10 万 + 请求。
2. 验票方式：支持身份证、二维码、人脸识别等多模态验证，需兼容线下闸机、手持设备、小程序等终端。
3. 核心能力：快速校验票务有效性（是否购票、未使用、在有效期内）、实时更新票务状态（防止重复使用）、抗突发流量与网络波动。
二、架构设计：分布式高可用架构
采用“边缘 + 中心” 混合架构，结合分层设计实现高并发与低延迟：
1. 终端层：边缘计算本地化
• 设备类型：景区闸机、手持验票终端、自助验票机等。
• 核心设计：
◦ 终端内置边缘计算模块，缓存热门票务数据（如当日该景区的有效票），支持离线验票（网络中断时可临时校验，恢复后异步同步）。
◦ 人脸识别终端本地部署轻量模型（如 MobileFaceNet），仅将特征值而非原始图像上传中心系统，减少带宽占用。
◦ 二维码验票采用“动态令牌” 机制：二维码包含过期时间（如 30 秒）+ 票务唯一 ID + 签名，防止截图复用。
2. 接入层：流量分发与隔离
• 负载均衡：采用“DNS 轮询 + LVS + Nginx” 三级负载：
◦ DNS 将请求解析到就近区域的集群（基于地理位置，如华东、华北）；
◦ LVS 做四层（TCP）负载，分发到 Nginx 集群；
◦ Nginx 做七层（HTTP/HTTPS）负载，按景区 ID / 终端类型分流到不同业务集群。
• API 网关：使用 Spring Cloud Gateway 或 Kong，实现：
◦ 限流：按景区 / 终端 IP 设置 QPS 阈值（如单景区每秒 5 万请求），超限返回 “稍候重试”；
◦ 熔断：当后端服务响应延迟 > 100ms 时，自动切换到备用集群；
◦ 鉴权：验证终端设备证书（防止伪造设备接入）。
3. 业务层：微服务拆分与高并发优化
按功能拆分微服务，通过集群化部署提升吞吐量：
• 验票核心服务：
◦ 接收终端的验证请求（身份证号 / 二维码 / 人脸特征），查询票务状态；
◦ 采用“读写分离 + 异步更新”：校验时读缓存 / 从库，验票成功后通过消息队列异步更新主库状态（标记为 “已使用”）。
• 票务数据服务：管理票务生命周期（购票、退票、有效期），与 OTA 平台 / 景区售票系统实时同步数据。
• 人脸识别服务：中心部署高精度模型（如 ArcFace），处理边缘终端无法识别的疑难案例（占比 < 5%），通过 GPU 集群加速计算。
• 高并发优化：
◦ 服务无状态化：基于 K8s 容器化部署，支持秒级扩容（根据 CPU / 内存使用率自动扩缩容）；
◦ 本地缓存：服务内存缓存（Caffeine）最近 10 分钟的验票记录，减少重复查询；
◦ 异步处理：非核心流程（如验票日志上报、统计分析）通过 Kafka 异步处理，不阻塞主流程。
4. 数据层：分存分治与一致性保障
• 缓存层：
◦ 主缓存：Redis 集群（分片 + 哨兵模式），存储 “景区 ID + 票务 ID”→“验票状态” 的键值对，设置 2 小时过期（覆盖单日有效票）；
◦ 本地缓存：终端 / 业务服务本地缓存热门景区的票务白名单（如当日销量前 100 的景区），减少 Redis 访问压力。
• 数据库层：
◦ 分库分表：按“景区 ID + 日期” 水平分片（如 MySQL+ShardingSphere），每个分片存储单个景区单日的票务数据，避免单库压力过大；
◦ 读写分离：主库负责写入（购票、退票、验票状态更新），从库（每个主库配 3 个从库）负责查询，通过 Binlog 同步数据；
◦ 数据归档：历史数据（过期票）迁移到低成本存储（如阿里云 OSS+ClickHouse），用于统计分析。
• 一致性保障：
◦ 验票状态更新采用“Redis 预扣 + 消息队列最终一致”：验票时先在 Redis 标记为 “已使用”（防止并发重复验票），再通过消息队列异步同步到数据库，失败则重试；
◦ 定时对账：每小时对比 Redis 与数据库的验票记录，修复不一致数据（如网络中断导致的同步失败）。
5. 监控与容灾：全链路可观测
• 监控体系：
◦ 指标监控：Prometheus+Grafana 监控 QPS、响应时间（P99 需 < 300ms）、错误率（<0.1%）、服务器负载；
◦ 日志追踪：ELK 栈收集终端 / 服务日志，通过 SkyWalking 实现分布式链路追踪，快速定位故障节点；
◦ 告警机制：当指标超阈值（如错误率 > 0.5%），通过短信 / 钉钉实时通知运维团队。
• 容灾设计：
◦ 多区域部署：核心服务在至少 3 个地域（如阿里云华东、华北、华南）部署，单区域故障时自动切换；
◦ 降级策略：极端流量下，关闭非核心功能（如人脸识别降级为二维码验票），优先保障基础验票能力；
◦ 应急方案：预设“手工放行” 接口，当系统全面故障时，由景区工作人员手动输入身份证号快速放行，事后补录数据。
三、关键技术选型
层级
技术栈
核心作用
终端边缘
嵌入式 Linux、TensorRT（轻量模型）
本地化验票、离线缓存
接入层
DNS 轮询、LVS、Nginx、Spring Cloud Gateway
流量分发、限流熔断
业务层
Spring Cloud、K8s、Kafka
微服务治理、弹性扩容、异步处理
数据层
Redis Cluster、MySQL+ShardingSphere
高并发缓存、分库分表存储
监控容灾
Prometheus、SkyWalking、ELK
全链路监控、故障定位
四、性能与安全保障
• 性能指标：支持每秒 20 万并发请求，平均响应时间 < 200ms，P99 响应时间 < 500ms；
• 安全防护：
◦ 数据传输：全链路 HTTPS 加密，终端与服务端采用双向证书认证；
◦ 防伪校验：二维码动态签名（结合时间戳 + 设备 ID）、身份证信息与公安系统脱敏比对；
◦ 防攻击：WAF 防护 SQL 注入 / DDOS，限制单 IP 请求频率。
通过“边缘本地化处理 + 中心分布式架构 + 缓存优先 + 异步最终一致” 的设计，可支撑国庆期间 10 亿人次的高并发验票需求，同时保障系统稳定性与用户体验。
