WiFi认证系统高可用：认证服务器挂了全员断网怎么办

WiFi认证系统有个绕不开的脆弱点：它自己也是一台服务器。员工或者顾客的上网请求，要先过它这一关才能放行。万一这台认证服务器挂了，新用户登不上，已经在线的也可能被踢。很多企业采购时没人问高可用，真出了故障才发现全公司或者全场集体断网。把高可用想清楚，WiFi认证系统才扛得住真实事故，而不是演示的时候好好的，一挂就全瘫。

单点故障的代价

如果认证只有一台服务器，它一宕机，新用户完全进不来，已经在线的如果会话到期也会掉。对商场意味着全场顾客连不上，对企业意味着全员停工。我们做方案会把认证服务器当成关键节点重点保护，单台是绝对不能接受的。单点故障的代价不是慢，是断。很多人评估WiFi认证系统只看功能有没有，不看挂了怎么办，等真挂了才意识到它是咽喉。高可用不是锦上添花，是上线前提。

双机热备怎么做

最基础的冗余是两台认证服务器做主备或者双活，一台挂了另一台无缝接。WiFi认证系统要把会话状态在两台之间同步，切换时用户无感。我们部署时会让主备实时同步在线会话，不是各管各的，否则一切换已登录的人全掉。双活比主备体验好，但配置复杂一些。小场景主备够用，大场景上双活。重点是会话要能继承，切换不丢状态。两台不是简单堆设备，是让故障对用户透明。

数据库别成新单点

认证服务器后面往往有账号数据库，如果数据库只有一份，服务器双了数据库挂了还是全体断。WiFi认证系统做高可用要把数据库也冗余，主从复制或者集群，别前面双机后面单库。我们见过单位认证服务器做了双活，结果数据库是单点，一次库故障全认证停。冗余要端到端，不能只冗余看得见的那层。数据库、缓存、配置，每一环都可能是隐藏的单点。把链路从头到尾过一遍，才知道哪里还脆。

负载均衡分散压力

除了故障，峰值压力也会打垮单台。晚高峰、促销日、开学季，认证请求集中爆发，一台扛不住就慢或者崩。WiFi认证系统前面要放负载均衡，把请求摊到多台。我们做容量时会按峰值而不是均值来配，均值配的到了高峰必塌。负载均衡还能在单台故障时自动摘掉，不影响整体。它既是高可用的组成部分，也是容量的保障。压力分散开，单台歇菜也不影响全局。容量和可用是一件事的两面。

会话保持住才叫无缝

切换发生时，最怕的是用户被要求重新登录。WiFi认证系统要把会话状态集中存储或者多机同步，切换后用户还是登录态，手机不弹窗、设备不掉线。我们部署时会把会话放在共享存储，认证节点无状态，任何一台都能接着服务。如果会话绑死在单台内存里，节点一换全得重来。会话外置是无缝切换的关键。用户感知不到切换，高可用才算做到位，否则切是切了但全员重登，体验一样崩。

故障要能秒级发现

高可用不是装完就不管，要能及时发现哪台出问题。WiFi认证系统把每台节点的健康、同步状态、响应时延做成监控，异常立刻告警。我们见过双机配了但其中一台悄悄挂了没人知道，等另一台也出问题才全体断。监控是冗余的配套，没监控的冗余是盲的。告警要送到能处理的人，别堆在一个没人看的群。节点健康可视化，故障在发生前或者刚发生时就被看到，才谈得上高可用。

演练比配置更重要

很多单位高可用是写进方案、配在文档，从没真切过。我们做交付会建议定期演练，拔掉主节点的网线，看业务是不是真无感、会话是不是真保持。不演练的高可用，真出事时往往发现同步没生效、切换脚本有坑。演练暴露的问题，比文档里写的可靠。周期性的切换演练，让冗余从纸面变成真实能力。WiFi认证系统作为上网咽喉，值得为它做几次演练，别等全体断网才验证。

降级比硬扛更现实

极端情况下，认证全挂了，是让全员断网，还是先放行保基本上网再补认证，是策略选择。WiFi认证系统可以设计降级，认证不可用时临时放行已备案的终端，事后补认。我们一般会对生产类、安全类终端开这个口子，纯娱乐的就不放。降级不是放弃认证，是故障时的止损。硬扛单点不如留个保底，至少关键业务不断。降级策略写进应急预案，出现实才不慌。高可用的尽头，是坏的时候还能兜住。

容灾演练要写进日常SOP

高可用方案做完，要落进运维的SOP，定期演练而不是纸面摆设。我们给客户的交付里会写明演练频率、步骤、判断标准，比如每季度拔一次主节点网线，验证业务是否真无感。演练发现的同步延迟、切换脚本缺陷，当场修掉。不写进SOP的容灾，平时没人想起，真出事手忙脚乱。SOP还要明确谁触发演练、谁观察指标、谁记录结果。高可用能不能在关键时刻顶住，取决于平时演练的认真程度，而不是方案写得有多漂亮。