必须配合日期动态生成key，因Bitmap无时间维度，共用key会丢失日期信息且导致单key膨胀、RDB/AOF暴增、主从延迟；用户ID须映射为非负整数offset，避免直接强转；BITCOUNT偏高多因key未清理或offset错位；5000万DAU下Bitmap体积约6.25MB，但需防ID稀疏浪费内存。
Bitmap 的 SETBIT 为什么必须配合日期动态生成 key？
因为 Bitmap 本身不带时间维度，SETBIT 操作的是单个 key 下的位图，如果所有用户都往同一个 key 写，就彻底丢失日期信息，无法做「某天 DAU」统计。强行用一个 key 存多年数据，还会导致单 key 膨胀、RDB/AOF 体积暴增、主从同步延迟加剧。
实操建议：
- key 命名格式统一用
"daus:20240520"或"daus:2024-05-20"，避免带空格或特殊字符 - 用业务侧（如 Go/Python）生成当天日期字符串，不要依赖 Redis 的
TIME命令——它返回的是服务器时间，可能和业务时区不一致 - 如果需要跨时区支持，key 中应显式带上时区标识，比如
"daus:20240520:cn"，别靠 guess
用户 ID 直接当 offset 用安全吗？
不安全。Bitmap 的 offset 是从 0 开始的非负整数，而真实用户 ID 往往是字符串（如 "u_123456789"）、UUID 或带符号的 long 类型。直接强转会出错或碰撞。
实操建议：
- 必须将用户标识映射为纯数字 offset，推荐用
hash(userId) % N，但要注意：N 要远大于预估日活，否则哈希冲突会导致漏计 - 更稳妥的做法是维护一张轻量 ID 映射表（例如用 Redis 的
HINCRBY分配自增 ID），让每个新用户获得唯一递增整数，再作为 offset - 切勿用
user_id.toString().hashCode()这类语言默认哈希——不同语言结果不一致，跨服务写读会错乱
BITCOUNT 统计当天 DAU 时，为什么有时结果偏高？
常见原因是没清空历史 key，或者误把多天 key 合并统计了。比如用 KEYS daus:* 扫出所有 key 再逐个 BITCOUNT，但中间有新 key 写入，就会重复或遗漏；更隐蔽的是：如果用户当天重复登录，SETBIT key offset 1 多次执行，只生效一次，这本身没问题，但若 offset 算错（见上一条），可能把 A 用户的 bit 写到了 B 用户的位置，导致两人被同时计为活跃。
实操建议：
- 每天凌晨用
DEL daus:20240519清理过期 key，别等自动过期——EXPIRE不保证准时，且BITCOUNT仍可执行 - 统计务必锁定单日 key，不要拼接通配符批量算；如需看周活，用
BITOP OR合并 7 个 key，再BITCOUNT，而不是累加 7 次结果 - 上线前用小流量抽样比对：取 1000 条当日登录日志，人工构造 offset 并
GETBIT校验，确认写入位置准确
DAU 超过 5000 万时，Bitmap key 体积和性能还扛得住吗？
扛得住，但得控制好 offset 上限。假设日活 5000 万，offset 最大值约 5000 万，对应 Bitmap 长度 ≈ 50,000,000 / 8 ≈ 6.25MB/key。Redis 单 key 体积在几十 MB 级别完全正常，但要注意：如果用自增 ID 映射，ID 稀疏度过高（比如最大 ID 是 2 亿，实际只用了其中 5000 万），Bitmap 会按最大 offset 分配空间，浪费严重甚至 OOM。
实操建议：
- 定期用
DEBUG OBJECT daus:20240520查看 key 实际内存占用，重点关注serializedlength字段 - 一旦发现稀疏率 > 30%（即有效 bit 数 / 总 bit 数 userId % 100 分 100 个 key，每个 key 独立
BITCOUNT再求和） - 别为了省事把所有用户塞进一个超大 Bitmap——运维排查、备份恢复、主从同步都会变慢，问题定位成本远高于多几个 key 的管理成本
