Redis Bitmap在稀疏ID场景下内存浪费严重，公式为(max_offset/8)+1字节；如ID=9999999则占约1.2MB，雪花ID易触发OOM；RoaringBitmap通过分桶+动态容器（Array/Bitmap/Run）按需存储，大幅压缩稀疏数据。
Redis Bitmap在稀疏ID场景下会吃掉多少内存？
直接看公式：(max_offset / 8) + 1 字节。比如你只存一个用户ID为 9999999（一千万），哪怕其他ID全是空的，Redis也会分配约 1250000 字节（≈1.2MB）——这还不是最糟的。如果ID是雪花算法生成的 1234567890123456789（19位），Redis会尝试分配超大字符串，极大概率触发 OOM command not allowed when used memory > 'maxmemory' 错误，或者直接拒绝写入。
常见错误现象：
- BITCOUNT 返回 0，但 SETBIT 成功 —— 实际是内存分配失败后静默截断
- INFO memory 显示
used_memory_human突增数MB，而业务只写了一个bit - 客户端报
NOAUTH Authentication required或READONLY You can't write against a read only replica，其实是 OOM 导致 Redis 主动降级为只读
RoaringBitmap为什么能压住稀疏数据的内存？
它不靠“预留空间”，而是按需分桶：把 32 位整数拆成高 16 位（桶索引）和低 16 位（桶内值）。只有真正有数据的桶才创建容器，空桶完全不占内存。对上面那个 ID=9999999 的例子，它落在桶 0x0098（十进制 152），只新建一个容器存 0x9687（十进制 38535），总开销通常不到 1KB。
关键点在于三种容器的动态选择：
-
ArrayContainer：存 ≤4096 个数时用 short[]，纯数组，查得快，空间线性增长（2 字节/数） -
BitmapContainer：≥4096 个数时自动切为 65536 bit 的 bitmap（即 8KB 固定），适合局部稠密 -
RunContainer：连续范围多时启用游程编码，比如存 1~10000，压缩后可能只要几百字节
注意：RoaringBitmap 不是 Redis 原生命令，必须通过客户端库（如 Java 的 org.roaringbitmap:RoaringBitmap）序列化后存进 Redis 的 String 类型，或用支持它的服务端模块（如 Redis Stack）。
什么时候该坚持用原生 Redis Bitmap？
满足全部三个条件时，原生 Bitmap 更轻、更快、更稳：
- 用户 ID 是连续或近似连续的整数，且最大值可控（例如注册用户数 ≤ 1000 万）
- 业务只需要做
SETBIT/GETBIT/BITCOUNT/BITOP这几类原子操作 - 没有跨天/跨用户聚合需求（比如“过去 7 天都签到的用户”需 AND 7 个 key，原生支持；而 RoaringBitmap 要先取回再 in-memory 计算）
典型场景：内部系统员工考勤（员工编号 1~5000）、小规模活动抽奖白名单（ID 按报名顺序递增）。
集成 RoaringBitmap 到 Redis 的实操避坑点
别直接 new RoaringBitmap().serialize() 往 Redis 里塞字节数组 —— 默认序列化格式含 Java 类名和版本号，跨语言/跨版本反序列化会失败。
- 务必用
roaringBitmap.serialize(new DataOutputStream(outputStream))，或调用toByteArray()（无 header） - 读取时用
RoaringBitmap.bitmapOf()初始化后.or(bitmapFromRedis)，别用new RoaringBitmap(inputStream)—— 它依赖 Java stream 协议 - 如果用 Redis Stack，优先走
RB.SADD等原生命令，避免手动序列化；否则记得设置合理EX过期时间，因为序列化后无法用BITCOUNT直接查 - 警惕
getLongCardinality()和getCardinality()区别：前者返回 long，后者 int，ID 超过 21 亿时用错会截断
最常被忽略的是：RoaringBitmap 的压缩优势只在写入后生效。如果你每次只塞一个 ID 就序列化一次，频繁小写入反而比原生 Bitmap 更慢、更碎 —— 应批量构建完再存。
