酒店WiFi认证系统中，无线控制器的冗余切换是一个高风险环节。正常情况下，主控制器处理所有认证和流量，备用控制器待命。主控制器故障时，备用控制器接管，这个过程叫故障切换。故障切换本身是几秒钟的事，但这几秒钟内，所有在线住客的认证状态可能丢失，住客需要重新认证才能上网。在大型酒店中，一次故障切换可能导致几百个住客同时掉线，前台瞬间被投诉电话淹没。

认证状态为什么会丢失

认证状态丢失的根因是主备控制器之间的认证会话不同步。Portal认证的会话信息通常保存在主控制器的内存中，包括终端MAC地址、认证时间、放行策略等。主控制器故障后，备用控制器没有这些会话信息，它看到的只是一批"未认证"的终端，于是把这些终端重定向到Portal页面，触发重新认证。

不同厂商的主备同步机制差异很大。有些厂商支持认证会话实时同步，主控制器的会话变化实时复制到备用控制器，故障切换后会话不丢失。有些厂商只支持配置同步，不同步运行时会话，故障切换后所有终端需要重新认证。选型时要问清楚厂商的同步机制，不能只看"支持双机热备"这个功能描述。

RADIUS认证状态的处理

如果酒店用的是RADIUS认证（比如802.1X），认证状态的处理更复杂。RADIUS认证的会话由RADIUS服务器和控制器共同维护。控制器故障切换后，新的控制器需要知道哪些终端已经通过认证。一种方式是RADIUS服务器保存认证会话，新控制器向RADIUS服务器查询终端的认证状态。但RADIUS协议本身不是为状态查询设计的，有些RADIUS服务器不支持这种查询。

另一种方式是RADIUS记账。认证通过后，控制器向RADIUS服务器发送记账开始消息；终端下线时发送记账结束消息。如果主控制器故障，终端实际没有下线，但记账消息不会发送。备用控制器接管后，可以查询RADIUS服务器上的活跃记账会话，判断哪些终端在线且已认证。这个方案依赖RADIUS记账的完整性和时效性，如果记账消息有延迟，查询结果可能不准确。

故障切换的快速重认证方案

如果认证状态同步无法做到完美，退而求其次的方案是快速重认证。故障切换后，备用控制器识别到一批未认证的终端，不立即弹出Portal页面，而是先尝试用终端的MAC地址做自动认证。如果该MAC地址在最近一段时间内（比如一小时内）有过成功的认证记录，直接放行，不弹Portal页面。这种方式需要认证系统保存近期的认证历史记录，用于故障切换后的快速恢复。

快速重认证不是完美方案，存在安全风险：如果住客退房后终端MAC地址未被清除，故障切换后可能被自动放行。所以快速重认证的窗口期不能太长，建议设为一小时或更短。超过窗口期的终端必须重新走完整认证流程。这个方案在多个项目中验证过，能大幅减少故障切换后的重新认证数量，把几百个终端的重新认证压缩到十几个。

故障切换的测试和预案

故障切换的可靠性不能只靠厂商的承诺，必须在项目验收时做实际测试。测试方法是：在正常运营时段，手动触发主控制器故障切换，观察住客终端的行为。测试关注几个指标：切换耗时、认证状态保留率、终端重连成功率、应用层感知（视频通话是否中断、网页是否需要刷新）。这些指标要达到甲方认可的阈值才能验收通过。

即使测试通过，也要准备故障切换的应急预案。前台需要知道故障切换时怎么安抚住客（比如告知"网络正在自动恢复请稍候一分钟"），运维人员需要知道怎么手动干预（比如手动触发重认证或临时关闭认证）。应急预案要形成文档，定期演练。很多酒店的故障切换预案只存在于运维人员的脑子里，人员变动后知识就丢了，出了问题手忙脚乱。

有些厂商还提供了控制器间会话同步的功能，主控制器的认证会话定期同步到备用控制器。但同步频率和同步范围需要调优，同步太频繁影响主控制器性能，同步太少故障切换后会话丢失率高。建议根据酒店的住客规模和认证频率调整同步参数，找到性能和可靠性的平衡点。