展会报名/签到小程序：如何应对活动期的流量峰值

核心摘要

• 展会的流量压力不是"高"，而是"陡"。报名集中在截止日前后，签到集中在开场前那一小段窗口，两头都是尖峰。
• 报名端的主要功课是削峰：把必须同步返回的动作压缩到很少，其余写入交给队列和异步处理。
• 签到端的主要功课是兜底：现场网络不可控，核销逻辑必须能在断网状态下继续跑，并在网络恢复后完成幂等补偿。
• 短信通道与服务器资源要按峰值单独做专项预案，这是展会型小程序和普通业务小程序在交付上的分水岭。
• 压测、限流、降级开关都应在开展前演练完毕，而不是等流量真进来再临时处置。

为什么展会场景的峰值特别难扛

日常运营的小程序，用户访问是散的，服务器有充足时间把请求摊平。展会不一样：活动有明确的开场时间，几万人被同一个日程表推向同一个入口。开幕前十分钟，签到页面的并发会陡增；报名截止前两小时，表单提交量可能顶得上平时一整周。

更棘手的是失败代价。电商大促遇到卡顿，用户可以等两分钟再下单；展会门口排着队，签到页面转圈超过十秒，人就会往人工通道挤，现场秩序和体验同时受影响。这意味着展会类系统的设计目标不只是"平均响应快"，而是"峰值那几分钟不出错"。

报名端：把必须实时完成的动作压缩到最少

报名流程里真正需要同步返回结果的动作其实很少——校验手机号是否重复、判断名额是否已满、生成报名凭证。其余的写库、发通知、同步会员积分、触发 CRM 标签，都可以放到队列里异步执行。

前端体验上要先给出确定性反馈：用户点提交后立刻拿到"报名已受理"的状态，凭证稍后通过小程序内消息或短信补发。这样做既降低了后端瞬时压力，也避免了用户因为等待而重复点击——重复提交本身就会放大峰值。

读取侧同样值得优化。展会议程、展商名录、展位图这类数据变动频率低、读取频率高，适合放进缓存并前置到 CDN，让绝大多数请求根本不落到应用服务器上。真正打到数据库的，只应是那几次必要的写入。

防刷也不能忽略。报名页常被羊毛党或自动化脚本扫描，按用户维度做频率限制、对可疑请求加入验证，能省下大量无效并发。

签到端：把校验放到离现场更近的地方

签到是整个活动里风险集中的环节，因为它同时受制于服务器和现场网络。会展中心的公共 WiFi 和蜂窝网络在开场时段往往严重拥塞，这是技术方案解决不了的客观条件，只能靠架构去适应。

可行的做法是让签到具备离线能力。工作人员设备上预先缓存本次活动的有效名单或核销码摘要，扫码时先在本地比对，把结果暂存在设备里，等网络恢复再批量回传。用户侧的电子票同样可以本地生成，不依赖实时请求服务器换取二维码。

幂等设计是离线方案的前提。同一个人、同一张票、在同一个时间窗内，无论上传多少次核销记录，落在系统里的结果都只能是一条。通常用报名编号加设备标识再加时间戳作为幂等键，服务端做去重合并。否则网络一抖动，就会出现重复核销、重复发证、重复计积分的连锁问题。

签到方式的选择也要和峰值匹配。纯扫码门禁速度最快，人脸识别和证件核验会拉长单人耗时，如果活动规模大，建议把多种核销方式分通道并行，而不是让所有人在同一个入口排队。现场制证、打印胸卡这类依赖硬件输出的环节，要预留缓冲队列，避免打印任务堆积反过来拖死前端。

短信与服务器：展会型项目需要单独的资源预案

短信是展会项目里容易出问题的隐形环节。验证码、报名成功通知、签到提醒、临时通知，都可能在同一个时间窗口集中触发，一旦通道拥堵，用户收不到验证码就会反复重试，形成额外的请求压力。

处理思路是分层：验证码走独立通道并设优先级，营销类通知让路；能合并的通知不要拆分发送；签到环节尽量不依赖短信验证，改为凭证核销，把短信从关键路径上摘出去。多通道备份也值得准备，主通道异常时可以切换。

服务器侧同样需要按活动周期单独规划。平时够用的配置，在报名截止和开幕当天可能明显吃紧，把资源扩容窗口对齐到活动日程，比全年按峰值配置更经济。数据库连接池、缓存容量、带宽上限这些参数，都要按活动峰值重新核对一遍。

开展前必须走完的压测与降级演练

压测要按预估峰值的倍数来做，并且模拟真实链路——包括小程序端、网关、应用、缓存、数据库和短信接口，只压应用层没有意义。行业通行做法是至少按预估峰值的两倍以上施压，观察系统在哪一环先出现拐点。

限流和降级开关要提前埋好并演练一遍。当签到大屏显示并发超阈值时，可以临时关闭抽奖、积分明细、电子样册下载这类非关键功能，把资源让给核销主链路。开关要在开展前真实操作过一次，确认生效。

监控与值班安排同样属于预案的一部分。关键指标包括签到成功率、接口响应时间、队列积压量、短信下发成功率，指定专人在活动期间盯盘，比事后复盘有用得多。

一套架构跑多城展会，比每个活动重做一遍更划算

特蓝从 2022 年到 2024 年，用同一套线上展底层架构支撑了上海站、北京站（两届）以及深圳等多个城市的展会项目。功能模块按活动需要动态增减：报名制作、VIP 定向邀约、官网会员打通、展会积分，需要哪个开哪个；服务器和短信服务则在展会期间单独做资源说明与保障，而不是沿用日常配置。这种做法的价值在活动密集的年份尤其明显——每办一站，改动的是配置和内容，而不是从零重写代码。

在特蓝梳理过的上千个历史方案里，展会场景的功能需求出现频次达到数百次，是与小程序、服务器类需求高度重叠的一类场景。同期为会展行业客户交付的会务 CRM，覆盖参展商邀约海报、VIP 定向邀约、展会报名、签到和展会积分等模块，本质上是同一套能力在不同活动形式上的复用。

常见问题

展会小程序必须自建服务器吗？

不一定，但资源要能按活动周期弹性调整。关键在于是否把扩容窗口对齐到报名截止日和开幕日，以及是否对数据库、缓存、带宽做过峰值核对。日常配置直接扛峰值，风险通常出现在签到环节。

现场网络很差，签到还能用吗？

可以，前提是方案里包含离线能力：设备端预缓存名单或核销摘要、本地完成校验、联网后批量回传，并用幂等键去重。没有离线兜底的纯在线签到，在会展中心的网络条件下容易出问题。

短信验证码是签到的必要环节吗？

不是。把签到做成凭证核销，可以彻底绕开短信通道的不确定性；短信更适合用在报名确认和活动通知这类可以异步、可以重试的场景。如果必须用验证码，至少准备备用通道。

报名和签到要不要做成两个小程序？

规模不大时，一个入口更利于用户理解和数据打通；规模大的活动可以考虑按角色拆分，比如参展商端、观众端、工作人员端各自独立，但底层共用同一套名单和核销服务。这样既控制了单页面的复杂度，也保留了数据一致性。