Redis位图如何保存用户在线状态

Redis通过Bitmap位图（SETBIT）高效保存亿级用户在线状态，仅需约12.5MB内存即可支撑1亿用户，远优于传统SET方案；它支持秒级日活统计（BITCOUNT）、实时在线查询（GETBIT）、批量原子操作（BITFIELD）及集合运算（BITOP），但需严格规范用户ID为非负整数、key按日期命名并设置合理过期时间，同时规避“未初始化key返回0导致误判”“跨天写入混乱”“重复心跳引发统计失真”等典型陷阱——真正考验工程能力的，从来不是命令本身，而是围绕位图构建的健壮数据生命周期设计。

为什么用 SETBIT 而不是 SET 存在线状态

直接存字符串（比如 SET user:1001 online）看似简单，但 1 亿用户就占 1 亿个 key，内存爆炸，且无法快速统计“今天上线了多少人”。SETBIT 把用户 ID 当作位偏移量，用单个 String 的二进制位表示在线/离线，1 亿用户 ≈ 12.5 MB 内存，还能秒级做交集、并集、计数。

常见错误现象：SETBIT user:online:20240520 1001 1 后查不到——因为没确认 key 是否过期、是否被误删；或用户 ID 是字符串如 "u_1001"，而 SETBIT 只接受非负整数偏移量，会报错 ERR bit offset is not an integer or out of range。

• 用户 ID 必须转成纯数字，且从 0 开始连续更省空间（不连续也没问题，只是中间空位也占内存）
• key 名建议带日期，如 user:online:20240520，避免无限累积；用 EXPIRE 设置 24–48 小时过期
• 不要用 HSET 或 SET 模拟位图——没有原生命令快，也不支持 BITCOUNT 这类聚合

GETBIT 返回值是 0/1，但容易误解为“存在与否”

GETBIT 查的是某一位的值，不是 key 是否存在。如果 key 不存在，它默认返回 0，而不是 nil 或 error。这意味着你不能靠 GETBIT 返回 0 就断定“用户不在线”，也可能是 key 根本没建过。

使用场景：心跳检测、实时在线判断。例如定时任务检查用户 1001 今天是否上线：GETBIT user:online:20240520 1001。

• 务必先确保 key 已创建（哪怕只执行一次 SETBIT user:online:20240520 0 0 初始化）
• 若需区分“未设置”和“明确设为离线”，得配合 EXISTS 判断 key 是否存在：EXISTS user:online:20240520
• 注意：Redis 位图是稀疏存储，高位未写过的区域不实际分配内存，所以 GETBIT 查一个超大 offset（如 10亿）不会 OOM，但会略慢

批量操作用 BITFIELD，别拼多个 SETBIT

给 1000 个用户同时标记在线，用循环发 1000 次 SETBIT 请求？网络开销大、原子性差、还可能部分失败。这时候该上 BITFIELD——它支持单命令多操作，且全部原子执行。

示例：把用户 1001、1005、1024 设为在线（值为 1），并读取 1001 当前状态：

BITFIELD user:online:20240520 SET i1 1001 1 SET i1 1005 1 SET i1 1024 1 GET i1 1001

参数差异：i1 表示有符号 1 位整数（实际只用 0/1），也可用 u1（无符号）。别写成 i8——浪费空间，且后续 BITCOUNT 仍按位算，不影响结果但易误导。

• BITFIELD 命令在 Redis 6.2+ 默认开启；老版本需确认配置中 bitmap-max-bytes 未被设为 0
• 如果操作跨天（比如凌晨写昨天的 key），注意 key 名要动态计算，别硬编码
• 不支持在 BITFIELD 里直接设过期时间，EXPIRE 得单独调用

统计日活用 BITCOUNT，但要注意 key 生命周期和精度

BITCOUNT user:online:20240520 是最常用也最容易翻车的操作。表面看是统计“有多少位是 1”，但实际含义取决于你怎么写入：是每次登录设 1，还是每次心跳都设 1？后者会导致重复计数。

性能影响：对一个 1 亿用户的位图，BITCOUNT 在现代 Redis（6.0+）里是 O(1)，因为内部用了 popcount 优化；但若 key 特别大（比如几百 MB），首次执行仍可能短暂阻塞主线程。

• 推荐每天零点用 BITCOUNT + DEL 组合导出数据，再删旧 key，避免长期堆积
• 如果需要“最近 7 天活跃用户数”，别用 7 个 BITCOUNT 相加——要用 BITOP AND 先算交集，再 BITCOUNT，否则重复用户会被重复计算
• 注意：BITCOUNT 统计的是整个 key 的所有位，如果你只写了前 10 万个用户，后面 9000 万位全是 0，它照样扫完——所以 key 范围要尽量贴近真实用户 ID 上限

真正难的不是命令怎么敲，而是设计时想清楚：用户 ID 是否全局连续、过期策略怎么配、跨天数据怎么衔接、以及——当运营突然要查“过去 30 天每天的独立访客”，你有没有预留好每天一个 key 的结构。

本篇关于《Redis位图如何保存用户在线状态》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于数据库的相关知识，请关注golang学习网公众号！