RedisBitmap实战要点，位操作的收益边界与内存陷阱
Redis Bitmap 并非独立数据类型，而是基于 String 的位操作集合。其核心价值在于用 1 bit 表达布尔状态，1000 万用户单日活跃仅需约 1.25 MB；但若映射不当（如直接使用雪...
Redis 中的 Bitmap 常被误认为是一种独立数据类型，实则不然。执行 TYPE key 返回的是 "string"，底层存储与普通字符串共享同一 SDS 结构——它本质上是一组作用于字符串字节序列的位级操作命令：SETBIT、GETBIT、BITCOUNT、BITPOS 与 BITOP。这种设计带来极高空间效率，也埋下了隐蔽的内存风险。
以一个典型场景为例：记录 1000 万用户在某日是否签到。若用 Set 存储用户 ID，按每个 ID 占 40 字节估算，需 400~600 MB；而采用 Bitmap，每位代表一个用户，1000 万位仅需 10⁷ ÷ 8 ≈ 1.25 MB（按 1000 进制计为 1.25 MB），压缩比达 300~500 倍。这一优势的前提是：状态能映射为连续、相对稠密、有界的非负整数——例如日期偏移量、用户 ID（需为紧凑整型）、序号等。
一旦映射失当，Bitmap 优势迅速逆转。雪花 ID（Snowflake ID）虽为 64 位整数，但高位时间戳导致实际值极大；若直接将其作为 offset 写入 SETBIT，即使未超 2³²−1 上限（约 42.9 亿），也可能因 offset 达千万级而瞬间分配数 MB 内存。例如 SETBIT key 100000000 1 会立即补零至 100,000,001 位，对应约 12.5 MB 字节串。更危险的是“看似安全却极稀疏”的写入：offset 在合法范围内但分布极度离散，导致 key 实际占用远超预期，成为隐形内存炸弹。
Redis 对 offset 的硬性限制源于 String 类型上限：512 MiB（即 2³²−1 位）。超过此值将报错 ERR bit offset is not an integer or out of range，且不截断。SETBIT 操作本身为 O(1) 时间复杂度，但首次大跨度扩展时需分配并清零新内存页，可能阻塞主线程——尤其在高并发写入稀疏 offset 时，易引发延迟毛刺。
核心命令中，SETBIT 与 GETBIT 构成基础读写单元。SETBIT 返回原位值（0 或 1），可天然实现幂等判重：首次写入返回 0，重复写入返回 1，避免额外 GETBIT 查询与竞态条件。GETBIT 在 offset 未超当前字符串长度但仍在 2³²−1 范围内时返回 0；越界则报错。值得注意的是，value 参数严格限定为 0 或 1，传入 2、-1、true 或空串均会校验失败。
高频组合模式包括：① 判重（依赖 SETBIT 返回值）；② 位图+过期策略（BITMAP 本身无 TTL，必须显式 EXPIRE）；③ 开关集合（一位一开关，如标签启用状态）；④ 多图聚合（BITOP OR/AND/XOR/NOT 实现交并补运算）。其中 BITOP 支持多源 key 合并，常用于用户画像交叉分析或权限叠加。
BITCOUNT 与 BITPOS 则负责统计与定位。BITCOUNT 默认按字节切分区间，若指定 start/end，其单位为 bit 位置；当区间跨越多个字节时，Redis 仍以整字节为单位处理，性能优于逐位扫描。BITPOS 用于查找第一个 0 或 1 的位置，支持从指定 offset 开始搜索，适用于快速定位空闲资源或异常状态。
在 .NET 环境下，StackExchange.Redis 2.8.16 + net10 可完整支持异步位操作：
上述代码中，uid 必须为紧凑整型 ID；若为 GUID 或手机号，应先通过哈希（如 MurmurHash）映射至合理范围，并评估碰撞概率与稀疏度——否则哈希后仍可能产生大 offset，得不偿失。
生产实践中需守住三条红线：第一，禁止将 UUID、手机号、雪花 ID 等稀疏标识直接作 offset；第二，所有 Bitmap key 必须配合 EXPIRE 设置过期时间，避免长期累积；第三，监控 key 大小（MEMORY USAGE）与大 offset 写入频率，防止突发内存增长。
值得补充的是，Redis 7.0 引入了 BITFIELD_RO 命令，支持只读位域访问，降低误写风险；而 BITCOUNT 的区间参数自 2.6.0 起支持，但早期版本需注意兼容性。此外，当业务需要动态增删“位实体”时，Bitmap 并非最优解——此时应考虑 RedisBloom 的布隆过滤器或 Sorted Set 配合 score 编码。
归根结底，Bitmap 是一把锋利的双刃剑：在状态稠密、映射严谨的场景下，它以极低开销支撑亿级布尔标记；一旦脱离前提，便从性能利器沦为内存隐患。工程师需在设计阶段明确数据分布特征，而非仅凭“省空间”直觉选用。
目前主流互联网应用中，Bitmap 多用于：用户日活统计、签到打卡、消息已读标记、风控黑白名单快速查询等固定周期、高密度布尔状态场景。其成功与否，不取决于命令是否掌握，而在于对数据本质的清醒认知。
