大型WiFi认证系统里，认证和计费往往由两套系统分别承担。认证系统负责判断用户能不能上网，计费系统负责按流量或时长收费。两套系统解耦的好处是职责清晰、扩展灵活、故障隔离。但解耦也带来了一个难题：认证状态和计费状态必须保持一致，否则会出现用户能上网但不计费、或者已经扣费却无法上网的情况。数据一致性是解耦架构下必须解决的核心问题。

认证和计费的数据流

一次典型的认证加计费流程是这样的。用户通过Portal或802.1X认证成功后，认证系统把认证事件发给计费系统。计费系统根据用户套餐、余额、策略等信息，决定是否允许用户开始上网。如果允许，计费系统创建会话记录，并开始统计流量或时长。用户下网或会话超时时，认证系统再次发送计费停止事件，计费系统结算本次会话。

这个流程里涉及多种数据：认证事件、计费开始请求、计费停止请求、中间更新请求、用户余额、套餐余量、会话状态。如果这些数据在传递过程中丢失、重复、顺序错乱，就会出现一致性问题。比如计费停止事件没有到达计费系统，计费系统认为用户还在上网，持续扣费。或者计费开始事件重复到达，计费系统给用户创建了两个会话，重复计费。

消息丢失和重复的处理

认证事件通常通过RADIUS计费报文或者消息队列传递。RADIUS计费报文基于UDP协议，本身不保证可靠传输。报文可能在网络中丢失，也可能因为服务器重启而丢失。为了应对这个问题，认证系统需要有重发机制。RADIUS标准里本身支持计费报文的重发，但重发可能导致重复计费，计费系统必须做幂等处理。

幂等处理的关键是每条计费报文都有唯一标识。计费系统收到重复报文时，根据唯一标识判断是否已经处理过，如果已经处理过就忽略，而不是重新创建会话。唯一标识可以来自报文里的计费会话标识，或者组合认证系统、NAS、用户、时间生成。设计时要确保唯一标识在全网范围内不重复，并且即使认证系统重启也不会重置。

顺序错乱和中间状态

计费报文到达计费系统的顺序不一定和实际发生顺序一致。计费停止报文可能比计费开始报文先到，或者中间更新报文延迟到达。计费系统不能简单假设所有报文都按顺序到。比较好的做法是维护会话状态机，任何报文到达时都先检查当前会话状态，按状态机规则处理。

比如收到计费停止报文时，如果对应会话还没有开始，就先暂存或按异常处理，不能凭空创建一条没有开始时间的会话。收到中间更新报文时，如果会话已经结束，就忽略或记录告警。这些细节看起来琐碎，但对账单准确性影响很大。

状态同步和定时对账

仅靠实时消息不能保证长期一致性。认证系统和计费系统之间要有定时对账机制。对账就是两边各拉一份会话清单，比对接入时间、结束时间、流量、时长、费用等字段。发现不一致时，要能自动修正或标记人工处理。对账频率可以根据业务规模设定，小到每小时一次，大到每天一次。

对账时还要注意时区问题。认证系统可能在服务器A上记录时间，计费系统在服务器B上记录时间，如果两台服务器时区不一致，或者时间没有同步，对账结果会错得离谱。所有服务器必须使用NTP统一时间，并且时间戳最好带时区信息。

异常场景的兜底设计

认证系统故障、计费系统故障、网络中断、数据库故障，这些异常场景都要提前设计。比如认证系统正常，但计费系统暂时不可用。如果认证系统必须等计费系统响应才能放行，用户就上不了网。如果认证系统直接放行，可能漏计费。折中方案是：计费系统不可用时，先按默认策略放行（比如允许使用免费时长或最小套餐），同时把事件排队，等计费系统恢复后补发。这样既保证用户体验，又避免大量漏计费。

WiFi认证系统的计费准确性直接影响收入和用户信任。解耦架构虽然灵活，但数据一致性保障不能松懈。消息幂等、状态机、定时对账、异常兜底，这些机制都要落实到位。甲方在验收时可能不会细看这些，但上线后账单出问题，第一个找的就是认证系统。把一致性保障做在前面，后面会少很多麻烦。