大型酒店的WiFi认证系统平时跑得好好的，一到下午三四点入住高峰期就开始出问题：住客反映认证页面打不开、验证码发不出来、填完点提交没反应。前台电话被打爆，技术部门手忙脚乱重启服务器。这种场景在很多酒店都出现过，根本原因是认证系统在高峰期的并发处理能力不够，但定位具体瓶颈点需要逐环节排查。

认证并发的瓶颈到底在哪一环

住客认证的完整流程是：终端连上WiFi，被重定向到Portal页面，填写手机号，后台发送短信验证码，住客输入验证码，认证服务器校验通过，放行上网。这个流程涉及多个环节：Portal页面服务器、短信网关、认证服务器、无线控制器的放行接口。任何一个环节处理不过来，整个流程就会卡住。

实际项目中，最常见的瓶颈不是认证服务器本身，而是短信网关。酒店入住高峰期，几百个住客几乎同时发起认证请求，每条请求都要发一条短信验证码。短信网关的发送速率是有限制的，一般每秒几十到几百条，如果瞬间涌入几百条请求，短信就会排队延迟发出。住客等了十几秒还没收到验证码，以为系统坏了，反复点击重新发送，请求量进一步放大，形成恶性循环。

Portal页面服务器也容易出问题。很多酒店的Portal页面部署在一台普通服务器上，用的还是单机Tomcat或Nginx，没有做负载均衡。高峰期几百个终端同时请求Portal页面，服务器处理器和内存飙升，页面响应变慢，住客等不及就关闭页面。

短信验证码的替代方案

要解决短信验证码的并发瓶颈，最直接的办法是不依赖短信。一键认证（基于运营商号码识别）是一个选择，住客连上WiFi后，认证系统通过运营商接口自动识别手机号，不需要住客手动输入和等验证码。这个方案的并发能力取决于运营商接口的处理能力，通常比短信发送快得多。但一键认证需要住客手机开启蜂窝数据，且运营商支持该能力，有些境外游客的手机不支持。

另一个方案是预认证。酒店管理系统在住客办理入住时，把住客的手机号和房号推送给认证系统，认证系统预先创建认证会话。住客连上WiFi后，认证系统根据终端MAC地址或手机号匹配预创建的会话，直接放行，不需要走完整的认证流程。这个方案把认证压力从高峰期分散到入住办理时段，有效削峰。但需要认证系统和酒店管理系统做接口对接，项目复杂度会增加。

认证服务器的扩容策略

如果短信瓶颈无法回避，就要在服务器层面做扩容。Portal页面服务器至少做双机负载均衡，认证服务器也要做主备或集群部署。扩容不是简单加机器，还要看软件架构是否支持水平扩展。有些认证系统用的是单机内存存储认证会话，加机器也没用，因为会话无法跨节点共享。这种情况下需要把认证会话存储改为Redis或数据库，实现多节点共享。

数据库层面也要注意。认证日志在高峰期写入量很大，如果数据库磁盘IO跟不上，认证请求会被阻塞。建议认证日志写入用异步方式，先把日志写到内存队列，再批量写入数据库。这样即使数据库写入慢，也不影响认证流程的处理速度。

高峰期应急预案

即使做了扩容，也要准备应急预案。最常见的是在Portal页面上增加等待提示和重试机制。住客点提交后，页面显示"正在认证中请稍候"，而不是白屏无响应。如果超过十秒未响应，自动提示"当前认证用户较多请重试"，并允许住客重新提交。这个看似简单的交互优化，能大幅减少前台投诉量。有些酒店还会在高峰期增加临时AP，分担认证终端的接入压力，虽然不能根本解决认证并发问题，但至少能减少因信号弱导致的认证失败。

还有些酒店在高峰期开启认证降级策略：当认证系统负载超过百分之八十时，自动切换为简化认证模式，只验证手机号不发短信验证码，或者直接放行所有终端，事后再做审计。这种策略在安全性和体验之间做了取舍，适合对安全性要求不高的经济型酒店。星级酒店如果采用降级策略，需要事后补全认证信息，确保合规日志完整。降级策略的触发条件和回切条件要提前定义好，不能由运维人员临时决定。