Sa-Token项目中用户在线时长统计的技术实现方案

在基于Sa-Token构建的统一认证中心系统中，用户在线时长的统计是一个常见但实现起来有一定复杂度的需求。本文将深入探讨这一问题的技术实现方案。

问题背景与挑战

用户在线时长统计看似简单，实则面临几个技术难点：

1. 会话终止检测困难：HTTP协议本身是无状态的，服务器难以准确感知用户何时真正"离开"
2. 大规模用户场景下的性能问题：当用户量达到百万级别时，实时监控每个用户的在线状态会带来巨大开销
3. 定义模糊：什么算"在线"？页面最小化算不算？网络短暂中断如何处理？

技术实现方案

方案一：WebSocket/SSE长连接方案

这是目前较为推荐的实现方式，核心思路如下：

1. 建立持久连接：用户登录后，前端与后端建立WebSocket或SSE长连接
2. 在线状态维护：后端使用Redis维护两个数据结构：
   • onlineUser(List类型)：存储当前在线用户ID
   • onlineDuration(ZSet类型)：以用户ID为member，累计时长为score
3. 定时任务处理：
   • 定期扫描onlineUser列表
   • 对每个在线用户，在onlineDuration中增加相应时长
4. 连接管理：
   • 连接建立时将用户ID加入onlineUser
   • 连接断开时从onlineUser移除

方案二：心跳检测方案

对于不能使用长连接的场景，可采用心跳机制：

1. 前端定期(如每分钟)发送心跳请求到后端
2. 后端记录最后一次心跳时间
3. 定时任务扫描所有用户，判断最后心跳时间与当前时间的差值
4. 超过阈值(如5分钟)视为离线，计算并记录在线时长

方案三：混合方案

结合上述两种方案的优点：

1. 优先使用WebSocket/SSE实现精确统计
2. 对于不支持长连接的客户端，降级为心跳检测
3. 后端统一处理两种来源的数据

实现细节与优化

Redis数据结构设计

onlineUser: [user1, user2, user3...]  # List类型，存储当前在线用户
onlineDuration: {user1: 3600, user2: 7200...}  # ZSet类型，累计时长(秒)
lastActive: {user1: 1672531200, user2: 1672531300...}  # Hash类型，最后活跃时间戳

并发处理

对于大规模用户场景，需要注意：

1. 使用Redis的原子操作保证数据一致性
2. 考虑分片处理在线用户列表
3. 合理设置定时任务执行频率，平衡实时性与性能

前端实现

前端需要处理多种场景：

// WebSocket示例
const socket = new WebSocket('wss://your-domain.com/ws');

socket.onopen = () => {
  // 发送认证信息
  socket.send(JSON.stringify({type: 'auth', token: 'xxxx'}));
};

// 定时发送心跳(备用方案)
setInterval(() => {
  fetch('/api/heartbeat');
}, 60000);

// 页面可见性变化处理
document.addEventListener('visibilitychange', () => {
  if (document.hidden) {
    // 页面隐藏时的处理
  } else {
    // 页面重新显示时的处理
  }
});

统计维度扩展

基于基础在线时长，可进一步实现：

1. 每日/每周/每月在线时长统计
2. 活跃时间段分析
3. 平均单次在线时长
4. 在线时长分布统计

总结

在Sa-Token生态中实现用户在线时长统计，WebSocket/SSE方案是最为精确和高效的选择。开发者需要根据实际业务场景、用户规模和技术栈选择适合的实现方式，并注意处理好边界情况和性能优化。通过合理的数据结构设计和前后端配合，可以构建出稳定可靠的在线时长统计系统。