WiFi认证在平时看起来对性能要求不高——客人连WiFi、弹Portal页、输入验证码，整个过程可能十几秒到几十秒才产生一次认证请求。但到了特定时间点，情况完全不同：酒店晚上八点到十一点是入住高峰，这段时间内可能有上百人同时开始认证流程；商场搞大促活动时，短时间内涌入的人流量可能是平时的五到十倍；学校宿舍晚上熄灯前，学生们集体连WiFi刷手机，认证请求瞬间爆发。这些场景下如果系统没有做高并发设计，轻则认证超时用户体验变差，重则整个认证服务不可用。

瓶颈通常不在CPU，在连接和IO。

做过性能分析的人应该知道，WiFi认证系统的并发瓶颈一般不出在CPU计算上，认证逻辑本身并不消耗多少CPU资源。真正的瓶颈通常在这几个地方：一是数据库连接池耗尽了——每个认证请求都去创建一个新的数据库连接，高峰期连接数暴涨导致数据库拒绝新连接，后面所有的认证请求全部排队等待。二是外部API调用的阻塞等待——短信网关的HTTP请求如果设置了10秒超时，高并发时有大量线程被阻塞在等待短信API响应上，线程池很快就会被耗尽。三是网络层的连接数限制——Linux的默认文件描述符上限是1024，认证服务作为高并发服务如果不对这个参数做调整，跑到几百并发就会因为文件描述符耗尽而拒绝新连接。

解决数据库连接池的问题，不是简单地把连接池设大就行。连接池越大，每个连接的利用率越低，而且数据库端的连接数也有上限。正确的做法是：在认证请求处理中尽可能减少和数据库的交互次数。把一些高频读取但低频变更的配置数据（比如认证策略、黑白名单规则）加载到内存缓存里，定期从数据库刷新，认证请求直接从内存缓存中读取，不查数据库。只有认证记录写入和用户状态更新这类必须落库的操作才走数据库。Redis这类内存数据库在这里也很管用——把认证过程中的临时状态（比如验证码、认证会话token）存在Redis里，既快又不会对主数据库造成压力。

外部API调用的阻塞问题，靠异步化来解决。当一个认证请求需要调用短信网关发送验证码时，主线程不应该同步等待短信API的返回结果，而是把发送任务丢进消息队列，然后用一个异步回调来接收发送结果。主线程立即返回"验证码已发送，请查收"给前端，后台的异步线程处理实际的API调用。这样即使外部API响应慢，也不会阻塞其他认证请求的处理。

连接数的问题需要从系统层面解决。

除了提高文件描述符上限，还需要注意连接复用的机制。认证服务对外的HTTP调用——比如调用短信网关、调用微信公众平台接口——应该使用连接池来复用TCP连接，而不是每次请求都新建一个连接然后关闭。HTTP Keep-Alive加上合理的连接池配置，在高并发场景下能减少大量的TCP握手开销。

还有一类容易被忽略的连接问题：认证网关和无线AP之间的连接。如果每个AP都和认证网关保持一个长连接用于推送授权指令，在AP数量多到数百个的情况下，网关的TCP连接数本身就是一个压力。这种场景下应该考虑把授权指令的推送机制从网关直连AP改为网关发布到消息中间件，AP从消息中间件订阅自己关心的消息。这样网关只需要和消息中间件维护少量连接，AP的数量增长不影响网关的连接负载。

限流和排队，是把峰值削平的有效手段。

即使做了各种性能优化，任何系统都有自己的物理承载上限。当并发请求超过了系统能处理的上限时，与其让所有请求一起进来导致系统崩溃，不如主动做限流和排队。限流是指对进入系统的请求速率做一个硬性的上限，超过这个速率的请求直接返回一个友好的提示"当前使用人数较多，请稍后再试"，并引导用户在10秒后自动重试。

排队则是把超过处理能力的请求放入一个有序队列里，按照先来后到的顺序逐一处理。用户端看到的是一个带倒计时的排队页面："您前面还有15位用户，预计等待30秒"。这个体验当然不如直接完成认证，但比系统直接崩溃、用户反复尝试要好得多。而且排队机制有时间平滑效果——用户看到排队页面后通常会等待，不会像系统崩溃时那样疯狂刷新加重负担。

限流和排队的参数需要和实际业务场景匹配。酒店场景的高峰期是晚间的三个小时，如果在第一个小时内就用光了限流配额，后面两个小时的客人就全部被拒了。所以限流策略应该是按时间窗口做平滑分配，而不是简单的固定速率。Queue的容量也需要结合业务量估算——一个300间客房的酒店，晚上八到十一点的预计认证请求量大概在400-600次，排队容量设计为高峰期半小时的请求量（约100次）是合理的。

灰度发布和压测，是确保高并发场景不出事的前提。

很多WiFi认证系统的高并发问题是在上线后才发现，然后紧急修复。如果能在上线前通过压测发现瓶颈，能避免大量投诉。压力测试不是拿几个并发线程跑一跑就完了，需要模拟真实的认证流程：设备连接WiFi、触发Portal重定向、加载认证页、填写认证信息、提交认证、收到认证成功响应——整条链路都要测，不能只测认证提交这一个点。

压测工具的选择上，JMeter、Locust这些通用工具都可以，但需要写好测试脚本来模拟完整的认证流程，包括HTTP重定向跟随和Cookie管理。压测的目标TPS应该按照业务高峰期预估值再乘以1.5倍的安全系数来设定。压测过程中要持续监控数据库连接数、Redis内存使用、网络吞吐量、CPU使用率、外部API响应时间的变化趋势，找到第一个出现的瓶颈点。

灰度发布是做风险控制的必要手段。新版本上线时不要一次性全量切过去，先切10%的流量观察24小时，确认认证成功率、响应时间、系统资源使用率没有异常后，再逐步扩大灰度比例。一旦发现指标恶化，立刻回滚。这个机制需要DNS负载均衡或者反向代理层面的流量控制能力来配合。

高并发设计不是一劳永逸的——用户量在增长、业务场景在变化、外部依赖在调整，性能瓶颈的位置也会跟着变化。把关键性能指标做成常态化监控，定期回顾性能数据，发现趋势性下降就提前干预，比等到用户大规模投诉了再排查要从容得多。