bitop and 能算出连续3天登录用户，因其对三天bitmap执行服务端原子按位与运算，结果中为1的bit位即三天均活跃的用户；但需确保所有bitmap基于同一连续user_id构建，避免因稀疏导致bitcount统计失真。
BITOP AND 为什么能算出连续3天登录用户
因为 BITOP AND 是服务端原子交集运算：把周一、周二、周三三天各自的 bitmap 按位做与（&）操作，结果中值为 1 的 bit 位，恰好对应那些三天都为 1 的用户——也就是连续3天登录的用户。它不依赖客户端遍历，毫秒级完成，适合日活百万级场景。
常见错误现象：BITOP AND result key1 key2 key3 执行后 BITCOUNT result 返回值远小于预期
- 根本原因是 bitmap 稀疏：你只设置了少量用户（比如 10 万个），但最大 offset 达到 9999999，导致 key 占用约 1.25MB，其中 99% 的 bit 是
0；BITCOUNT统计的是整个内存块里所有1，不是“有效用户数” - 别用业务 ID（如手机号、UUID）直接当 offset，必须用连续分配的
user_id，且确保最大user_id2^32） - 检查实际有效范围：
BITPOS key 1 -1查最后一个1的位置，确认是否合理
key 命名和 offset 必须对齐，否则结果全错
连续登录判定的前提是：同一位 offset 在三天 key 中代表同一个用户。一旦偏移错位，AND 结果就失去语义。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 推荐格式：
login:20260902、login:20260903、login:20260904，每天一个 key - offset 必须是用户在系统内的连续编号（如数据库自增
id），不能是时间戳、哈希值或随机数 - 所有 key 必须使用相同时区（建议统一转为 UTC+0 后计算日期），避免因本地时区差异导致某天 key 漏写
- 如果用户量增长，需提前规划 offset 上限；超 43 亿用户需分片，BITOP 不再适用
BITOP 最多支持 16 个 key，3 天完全够用但要注意阻塞
BITOP AND 是 Redis 单线程同步执行的，虽然 3 个 key 的运算通常在 0.1ms 内完成，但在高并发写入高峰期仍可能轻微抖动。
- 实测万级 QPS 下稳定，但如果单个 bitmap 接近 100MB（对应约 8 亿用户），主线程阻塞会升至几毫秒
- 不要在主从架构的从节点上执行 BITOP —— 它不会同步到从库，且从库执行会报错
- 生产环境建议加超时控制：客户端调用时设
timeout=100ms，失败则降级为客户端校验（读取三天 key 后用集合求交） - Redis 6.2+ 默认启用
BITFIELD_RO安全模式，但 BITOP 不受此限制，无需额外配置
BITOP 后不能直接用 BITCOUNT 统计“用户数”，得先清理稀疏空间
这是最容易被忽略的坑：你想要的是“有多少个用户连续登录3天”，但 BITCOUNT result 返回的是“结果 bitmap 中所有 1 的个数”——而这个 bitmap 长度由最大 offset 决定，不是有效用户数。
- 正确做法：用
BITPOS result 1 0找第一个1，再用BITPOS result 1 -1找最后一个1，两者差值 +1 就是有效区间长度；再在这个区间内用BITCOUNT result 0 N（N 为最后偏移量）才接近真实人数 - 更稳妥方案：BITOP 后立刻用
STRLEN result看实际字节数，若远大于(max_user_id / 8) + 1，说明存在严重稀疏，应重建 key 或改用用户维度方案 - 长期运行系统建议每日凌晨跑一次
BITOP AND+BITCOUNT校验，并记录稀疏率，超过 95% 就触发告警
