SETBIT是十亿级签到场景的核心命令，因其原子写入、自动扩容、1bit存储优势，避免GETBIT+SETBIT的额外开销；需确保offset连续、key按时间或分桶拆分，并警惕稀疏offset导致内存浪费。
SETBIT 是你在十亿级签到场景里真正该盯住的第一个命令，不是 BITCOUNT，也不是 BITOP——它决定了你能不能把“签到”这个动作压进 1 bit，而不是浪费在字符串或整数上。
为什么必须用 SETBIT 而不是先存再查？
用户签到是典型的“写多读少+高并发+状态极简”场景。如果用 GETBIT 先查再 SETBIT 写，会多一次网络往返和一次 Redis 查找，QPS 上不去；而直接 SETBIT key offset 1 是原子写入，返回原值还能判断是否重复签到。
-
SETBIT自动创建 key，无需预分配空间（未设置的位默认为 0） - offset 超过当前长度时，Redis 会自动填充中间的 0 字节，不报错也不丢数据
- 注意：offset 最大支持 2^32−1（约 42 亿），对应 512MB 字符串上限，10 亿用户 × 365 天 = 365 亿位 → 超了，得按月/周分 key，比如
sign:202604:user1001
BITCOUNT 统计日活时，别漏掉时间窗口对齐
统计“今天活跃用户数”，不是简单跑一遍 BITCOUNT sign:20260417 就完事。真实业务中，日期和 offset 的映射必须严格对齐，否则跨月、跨年会错位。
- 推荐方案：以自然日为单位，每天一个 key，offset = 当日是该月第几天 − 1（即 4 月 1 日 → offset 0，4 月 17 日 → offset 16）
- 若用“自 Unix 时间戳起的天数”作 offset（如
timestamp / 86400），则 key 可复用，但需确保所有客户端时区一致，否则凌晨时段可能写错 day -
BITCOUNT默认统计整个字符串，如果只关心前 31 位（一个月），加参数BITCOUNT sign:20260417 0 30（注意：第三个参数是字节索引，不是位索引！30 字节 = 240 位，要算准）
连续签到怎么算？BITOP + BITCOUNT 组合有坑
要找出“过去 7 天全签到”的用户，不能只靠单个 key 的 BITCOUNT，得把 7 个 key 做 AND 运算，再数结果中 1 的个数。但这里有两个关键约束：
-
BITOP AND destkey key1 key2 ... key7要求所有 key 长度一致；如果某天 key 还没写过（比如新用户第一天签到），Redis 会把它当空字符串（全 0），导致 AND 结果全 0 —— 所以必须保证每天都有 key（哪怕全 0），可用SET sign:20260410 ""初始化 - AND 结果保存在
destkey中，该 key 会一直存在，下次再用得先DEL或重命名，否则污染后续统计 - 更轻量的做法：用 Lua 脚本一次性读取 7 个 key 的对应位（如 offset=16 表示今天），逐位 AND，避免生成中间 key
内存真能压到 12.5MB？小心 offset 稀疏带来的浪费
理论计算：10 亿用户 × 1 bit = 12.5MB，前提是所有用户都集中在同一个 key 里且 offset 连续。但现实中，用户 ID 分布稀疏，比如用 user_id 作 offset，user_id=1 和 user_id=1000000000 同时存在，Redis 就得分配至少 1000000000 / 8 = 125MB 空间来容纳这两位 —— 中间全是 0 字节，但内存占着。
- 正确做法：不用原始 user_id 当 offset，改用递增的内部 UID（如 MySQL 自增 id 或号段发号器），确保 offset 密集连续
- 或者分桶：按 user_id % 1000 分成 1000 个 key，每个 key 的 offset = user_id / 1000，这样单 key 最大 offset 控制在百万级以内
- 用
DEBUG OBJECT key查看实际内存占用，比理论值高 2–3 倍很常见，这是 SDS 内存对齐和元数据开销导致的，不是 bug
真正卡住性能的，从来不是命令本身，而是 offset 怎么映射、key 怎么拆、空洞怎么填。这些细节不抠清楚，10 亿数据一跑就内存爆表或结果错乱。
