Redis 的 Bitmap 本质上不是“新数据类型”，而是把 String 当成一段连续的二进制位数组来用：每一位只有 0/1，非常适合做“海量布尔状态”的低成本存储与聚合统计 ✅🙂
1）核心特性：为什么 Bitmap 适合“业务运营数据”
极致省内存：1 个状态只占 1 bit。粗算公式：
N 个用户状态 ≈ N / 8 字节（不含 key 与元数据）。天然支持聚合：支持按位统计、按位或/与/异或做集合运算（活跃、留存、交集、并集）。
高性能：单点读写位（GETBIT/SETBIT）接近 O(1)，适合高并发写入。
2）命令实战：最常见的“签到/活跃”模型
示例：按“天”记录用户是否活跃（offset = userId）
SETBIT active:20251227 10001 1 GETBIT active:20251227 10001 BITCOUNT active:20251227解释：
SETBIT key offset value：把active:20251227的第10001位设置为1，表示该用户当天活跃。offset 越大，底层字符串会扩容，因此 userId 若跨度极大要评估内存。GETBIT：读取该用户当天是否活跃，返回 0/1，适合接口秒级判断。BITCOUNT：统计整张位图中为 1 的数量，可直接得到当天 DAU（日活）。
3）留存/交集：用位运算直接算（企业最爱这一步）
BITOP AND retain:20251226_20251227 active:20251226 active:20251227 BITCOUNT retain:20251226_20251227解释：
BITOP AND destkey key1 key2：对两天活跃位图做按位与，只有两天都为 1 的用户位才会保留为 1，这就是 次日留存人数。BITCOUNT destkey：统计留存人数，避免把明细拉回业务层计算，省网络与 CPU。
4）Bitmap 工作流（文本流程图）
定义 <span style="color:red">Key 维度</span>（按天/按月/按活动） ↓ 设计 <span style="color:red">offset 映射</span>（userId / dayIndex / featureIndex） ↓ 用 <span style="color:red">SETBIT</span> 写入状态（0/1） ↓ 用 <span style="color:red">GETBIT</span> 做实时判断 ↓ 用 <span style="color:red">BITCOUNT / BITOP</span> 做统计与交并集5）对比表：什么时候 Bitmap 赢，什么时候别硬上
| 需求场景 | 推荐方案 | 原因 |
|---|---|---|
| 海量用户 0/1 状态（签到、是否活跃、是否命中） | Bitmap | 极省内存 + 易聚合 |
| 需要保存“具体成员列表”并做增删查 | Set | Bitmap 只能表达位，不保存成员信息 |
| 只要估算去重（允许少量误差） | HyperLogLog | 更省内存，但不可回溯明细 |
| 要保存计数/多字段位段（如 3bit 等级、5bit 权重） | BITFIELD | 位段写入更紧凑（需严谨规划） |
6）三条“务实避坑”建议（很关键）
避免超大稀疏 offset：例如直接用 10 亿的 userId，会导致位图扩容到对应字节，内存瞬间膨胀。可先做 id 压缩映射或按区间分片 key。
维度要可控：常用按天/按月建 key，并配合 TTL，避免历史数据无限增长。
统计尽量在 Redis 内完成：BITOP + BITCOUNT 比“把数据拉回应用层遍历”更稳、更省成本。🙂
如果你告诉我你的具体业务（例如：签到按“用户维度”还是按“日期维度”、userId 是否连续、日活量级），我可以给你一套更贴近生产的 key 设计与分片策略，让 Bitmap 既省内存又不踩扩容雷。
