★ FEATURED ARTICLE 1. 项目概述最近在开发一个需要实时显示在线用户列表的功能要求能够精确控制每个账号只能在一个终端登录。经过技术选型最终决定基于Redis的Zset数据结构来实现这个功能。这种方案不仅性能优异还能很好地满足单端登录的业务需求。在实际项目中在线用户管理是个常见需求。比如在线教育平台需要显示当前听课的学生社交应用要展示好友在线状态协同办公工具需实时同步团队成员活跃情况。传统数据库方案在面对高并发场景时往往力不从心而Redis凭借其内存存储特性和丰富的数据结构成为解决这类问题的利器。2. 核心需求解析2.1 功能需求拆解我们需要实现的在线用户列表功能包含以下核心需求实时记录用户登录/登出状态快速查询当前在线用户列表确保同一账号不能同时在多个终端登录支持按最后活跃时间排序自动清理长时间未活动的用户2.2 技术选型考量为什么选择Zset而不是其他Redis数据结构Hash虽然可以存储用户信息但无法实现自动排序Set可以存储在线用户集合但缺少时间维度信息List不适合快速判断元素是否存在String存储结构过于简单无法满足复杂需求Zset的独特优势自带score机制天然支持按时间排序元素唯一性保证自动处理重复用户O(logN)的查询效率性能优异内置范围查询方便获取活跃用户3. 详细设计与实现3.1 数据结构设计我们使用一个Zset来存储所有在线用户Keyonline:usersMember用户ID如user:123Score最后活跃时间戳毫秒级示例命令ZADD online:users 1672531200000 user:1233.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:1233.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故障也能从数据库恢复最新状态。不过这会增加系统复杂度需要根据业务重要性权衡。
阅读完成 · 觉得有帮助？
