酒店WiFi实名认证的容量怎么做：三处瓶颈一次算清
酒店WiFi实名认证上线前，管理者常问一句话：这套系统能不能扛得住。这句话背后其实是三个不同的容量问题，经常被混在一起问。认证平台能不能扛住并发，短信通道能不能按时把验证码送到，出口带宽够不够所有人同时用。三处瓶颈的性质完全不同，瓶颈一堵，现象也不一样，得分开算、分开管，才能把容量这件事一次算清。
认证平台：并发的第一道闸
客人集中入住、会议进场、节假日高峰，短时间内大量终端同时发起认证请求，认证平台要在这几分钟内完成身份核验和放行。这块的容量指标是并发在线和并发认证请求。如果平台扛不住，症状是认证页面打开慢、转圈、提交无响应，客人卡在认证这一步进不去。
并发能力的评估要结合认证平台的部署形态和硬件规格。集中式平台和云平台、本地服务器和租赁服务，各自的并发上限不一样，不能拿厂商宣传数字直接套用。判断方法是在项目范围内做并发验证：按酒店房间数推算高峰同时认证的终端数，再考虑团队入住、会议等突发场景，按一定冗余量确定目标值，通过压测确认平台是否满足。性能指标必须绑定硬件规格、网络拓扑、并发模型和压测方法，脱离场景承诺并发数没有意义。
短信通道：验证码能不能按时到
短信认证依赖验证码送达，通道就成了第二道瓶颈。通道质量波动、运营商接口异常、手机号格式问题，都会导致验证码延迟或收不到。症状很直接：客人点了获取验证码，半天没收到，然后开始投诉。
短信通道的处理思路是多运营商冗余。配置多个通道，一个通道异常自动切换，同时在认证页面提供手机号格式校验和重新获取按钮，后台实时监控短信下发状态，异常及时告警。日常还要看短信到达情况，结合认证成功率一起分析。国际短信涉及的目的国家和运营商规则差异更大，成本与到达率需要单独评估，通常不作为外宾认证的首选通道。
出口带宽：最后一个总闸
认证通过了，验证码也到了，客人能不能顺畅上网，取决于出口带宽。这处瓶颈的症状和前两处不同：认证没问题，但视频卡、网页慢、延迟高。高峰期所有客人的流量同时压向出口，总带宽不够，或者个别大流量用户抢占，体验就会崩。
出口容量的判断依据是酒店的实际并发在线数和业务流量构成。房间数、平均在线终端数、客群上网习惯（商务客视频会议多，旅游客视频娱乐多），共同决定需要的带宽。判断够不够，要看高峰时段的带宽使用率数据，而不是凭感觉。同时结合带宽分级策略，经营流量和客用流量分开保障，避免客人流量挤占经营网络。
别忘了无线侧和认证会话的容量
三处瓶颈之外，还有两个容易被忽略的容量点。一个是无线侧的接入容量：AP能同时承载多少终端、单台AP在密集客流的并发表现，直接影响客人能不能稳定连上网络。客房、大堂、会议室的AP部署密度要按并发终端数倒推，不是按房间数一房一个就行。另一个是认证会话的容量：认证通过后的在线会话数、无感知认证的终端记录数，这些数据会随着时间积累，系统要能承载并保持查询效率。
容量验证的方法建议分两步。第一步是静态测算，按酒店房间数、平均每房终端数、公共区域并发估算高峰期总终端数，再乘以认证请求的峰值系数，得出认证平台和短信通道的目标容量。第二步是动态验证，在试点楼层或真实高峰时段跑一次，观察三个环节的实际表现，把测算值和实测值对照，偏差大的环节单独排查。这样验证出来的容量结论才对应这家酒店的真实情况，而不是沿用别处的经验数字。
容量要留扩展的空间
酒店的网络需求是增长的。房间数可能增加，会议中心可能扩建，客人的多设备比例在上升。选型时就要考虑扩展能力：认证平台能否平滑扩容，短信通道能否增加冗余，出口带宽能否升级，无线设备能否按需补点。容量规划不是一次性的工程，而是给未来留出余量。规划时按当前需求加一定冗余设计，运营中再按数据逐步调整，既避免一开始买贵，也避免高峰期捉襟见肘。酒店WiFi实名认证的容量规划，最终服务的是一个目标：无论什么时候客人集中上网，认证、短信、带宽三个环节都能接得住，客人在前台、在房间、在会场，都不会因为网络容量问题被卡在半路。
三处瓶颈要一起验证
把三处瓶颈分开算清楚之后，还要合起来验证一次。真实高峰场景下，并发认证请求、验证码下发、出口流量是同时发生的，任何一处掉链子都会表现为整体体验差。上线前做一次高峰模拟：按预计并发发起认证，观察平台响应时间、验证码到达情况、认证后的上网体验，把三处数据放在一起看。这样算出来的容量，才是这家酒店自己能用上的数字，不是三份互不相干的参数。
容量规划做完，还要留出运营余量。淡季按基础需求配置，旺季或会议档期可以临时扩容。认证平台的扩展能力、短信通道的冗余数量、出口带宽的可升级空间，都应该在选型时一并考虑。酒店WiFi实名认证的容量问题，从来不是单一指标的比拼，而是整条链路在高峰时刻都不掉链子。