必须用 SETBIT 的场景是需精确记录并支持随机查询（如判断某用户是否点赞），而 PFADD 仅适用于允许误差的去重总数统计，二者不可互换。
SETBIT 和 PFADD 不是互换方案，选错会导致数据不可用或统计失真。千万级点赞场景下，必须用 Bitmaps；HyperLogLog 只适合“总点赞数”这类去重计数，不能查“某用户点没点”。
什么时候该用 SETBIT 而不是 PFADD
Bitmaps 解决的是「精确记录 + 随机查询」问题，HyperLogLog 解决的是「只关心总数 + 允许误差」问题。
- 需要支持
GETBIT content:10086:likes 12345判断用户 12345 是否点赞过内容 10086 → 只能用SETBIT - 只需要知道“内容 10086 总共被多少不同用户点过赞”，且允许 ±0.81% 误差 →
PFADD+PFCOUNT可行，但丢掉了所有用户粒度信息 - 想查“最近 7 天连续点赞的用户”或“和好友共同点赞的内容” → 必须用 Bitmaps，靠
BITOP做位运算实现
SETBIT 的 offset 设计容易踩的坑
用户 ID 直接当 offset 用，是新手最常犯的内存浪费错误。
- 如果用户 ID 是自增 long 类型（如 10000000001），直接
SETBIT content:10086:likes 10000000001 1，Redis 会分配约 1.25GB 内存来撑开这个偏移位置（因为 offset 按 bit 算，10000000001 bit ≈ 1.25GB 字符串） - 正确做法：做 ID 映射，例如用 Redis 的
INCR维护一个全局用户映射表user:id2seq:10000000001 → 23456，再用 23456 当 offset - 更轻量方案：若业务用户 ID 固定以
10000开头，统一减去该 base：offset = userId - 10000，前提是确认不会出现负 offset - 注意：
SETBIT第一次写高位 offset 时会阻塞 Redis 主线程，高并发写前建议预热或分批初始化
集群环境下 BITCOUNT 和 BITOP 的实际限制
Redis Cluster 不支持跨 slot 的多 key 命令，而 BITOP 必须所有 key 在同一节点 —— 这一点文档很少强调，但线上极易出错。
-
BITCOUNT content:10086:likes没问题，单 key 命令自动路由 -
BITOP OR result:week likes:mon likes:tue likes:wed要求likes:mon、likes:tue、likes:wed都落在同一个哈希槽，否则报CROSSSLOT Keys in request don't hash to the same slot - 解决办法只有两个：
– 所有日期类 key 用相同哈希标签，比如都加{content:10086}前缀：{content:10086}:likes:20260520
– 或改用客户端聚合：先MGET各 key 的 bitmap 字符串，本地做位运算（仅适用于小规模） -
BITCOUNT的[start end]参数单位是字节，不是 bit；误写成BITCOUNT key 0 100想查前 100 个用户？其实查的是前 100 字节 = 前 800 个 bit —— 容易漏判低 ID 用户
真实压测中，一个 5000 万用户规模的点赞系统，用纯 Set 存储需 3.2GB 内存，Bitmaps 仅需 6.2MB（按用户 ID 映射后 offset ≤ 50M），但一旦 offset 设计失控或跨 slot 乱用 BITOP，集群就会退化成单点瓶颈。关键不在“能不能用”，而在“怎么让 offset 可控、key 可路由、运算可收敛”。
