1. 项目概述
最近在开发一个需要实时显示在线用户列表的功能，要求能够精确控制每个账号只能在一个终端登录。经过技术选型，最终决定基于Redis的Zset数据结构来实现这个功能。这种方案不仅性能优异，还能很好地满足单端登录的业务需求。
在实际项目中，在线用户管理是个常见需求。比如在线教育平台需要显示当前听课的学生，社交应用要展示好友在线状态，协同办公工具需实时同步团队成员活跃情况。传统数据库方案在面对高并发场景时往往力不从心，而Redis凭借其内存存储特性和丰富的数据结构，成为解决这类问题的利器。
2. 核心需求解析
2.1 功能需求拆解
我们需要实现的在线用户列表功能包含以下核心需求：
- 实时记录用户登录/登出状态
- 快速查询当前在线用户列表
- 确保同一账号不能同时在多个终端登录
- 支持按最后活跃时间排序
- 自动清理长时间未活动的用户
2.2 技术选型考量
为什么选择Zset而不是其他Redis数据结构？
- Hash：虽然可以存储用户信息，但无法实现自动排序
- Set：可以存储在线用户集合，但缺少时间维度信息
- List：不适合快速判断元素是否存在
- String：存储结构过于简单，无法满足复杂需求
Zset的独特优势：
- 自带score机制，天然支持按时间排序
- 元素唯一性保证，自动处理重复用户
- O(logN)的查询效率，性能优异
- 内置范围查询，方便获取活跃用户
3. 详细设计与实现
3.1 数据结构设计
我们使用一个Zset来存储所有在线用户：
- Key：online:users
- Member：用户ID（如user:123）
- Score：最后活跃时间戳（毫秒级）
示例命令：
ZADD online:users 1672531200000 "user:123"3.2 单端登录实现方案
为确保单端登录，需要三个关键操作：
- 登录时检查并踢出旧会话：
# 原子性操作脚本 local existing = redis.call('ZSCORE', KEYS[1], ARGV[1]) if existing then redis.call('ZREM', KEYS[1], ARGV[1]) end redis.call('ZADD', KEYS[1], ARGV[2], ARGV[1]) return 1- 心跳维持时更新最后活跃时间：
ZADD online:users NX 1672531260000 "user:123"- 登出时移除用户：
ZREM online:users "user:123"3.3 在线用户查询
获取当前所有在线用户（按最后活跃时间倒序）：
ZREVRANGE online:users 0 -1 WITHSCORES查询最近5分钟活跃的用户：
ZREVRANGEBYSCORE online:users +inf [当前时间戳-300000] WITHSCORES3.4 会话超时处理
使用Redis的过期机制自动清理不活跃用户：
# 定期执行清理脚本 ZREMRANGEBYSCORE online:users -inf [当前时间戳-超时阈值]4. 性能优化技巧
4.1 内存优化方案
- 用户ID存储优化：
- 使用数字ID而非字符串（如123代替"user:123"）
- 必要时采用压缩算法处理长用户ID
- 时间戳存储优化：
- 使用相对时间戳（减去基准时间）
- 根据精度需求选择秒级或毫秒级
4.2 查询性能优化
- 分页查询实现：
# 获取第2页数据，每页20条 ZREVRANGE online:users 20 39 WITHSCORES- 热点数据缓存：
- 对频繁访问的在线用户数进行缓存
- 使用Redis的INCR/DECR维护计数
5. 常见问题与解决方案
5.1 数据一致性保障
问题场景：网络抖动导致心跳失败，用户被错误踢出
解决方案：
- 实现心跳重试机制（指数退避算法）
- 设置合理的心跳间隔和超时阈值
- 客户端本地缓存最后活跃时间
5.2 大规模用户处理
当在线用户量超过百万时，需考虑：
- 分片存储：按用户ID哈希分片到多个Zset
- 冷热分离：活跃用户与不活跃用户分开存储
- 异步处理：使用Redis Stream处理批量操作
5.3 监控与报警
关键监控指标：
- 在线用户数波动
- Zset内存增长情况
- 命令执行耗时
- 心跳成功率
推荐配置报警规则：
- 在线用户数突降50%以上
- ZADD命令平均耗时>10ms
- 内存使用超过预警线
6. 生产环境实践心得
在实际部署时，我们总结了以下经验：
- 时间同步很重要：确保所有服务器时间同步，避免因时间差导致误判
- 合理设置超时：根据业务特点调整会话超时时间（IM应用5-15分钟，后台系统30-60分钟）
- 客户端容错：实现断线自动重连和状态恢复机制
- 压力测试：模拟10万+并发连接测试系统表现
- 备份方案：定期持久化在线用户列表到数据库
一个容易忽视的细节是客户端时区问题。我们曾遇到用户被异常踢出的情况，最后发现是因为移动端设置了错误时区，导致心跳包中的时间戳偏差过大。解决方案是在服务端统一使用UTC时间，并增加时间戳有效性校验。
对于特别关键的系统，可以考虑实现双写机制：先在Redis快速更新状态，再异步写入数据库。这样即使Redis故障，也能从数据库恢复最新状态。不过这会增加系统复杂度，需要根据业务重要性权衡。
