Bitmaps 比 Set 节省多少内存？
如果用传统的 SET 来存储一千万用户某一天的签到状态，会是什么景象？每个 user_id 在 Redis 的 String 编码下，光是 key 和 value 的开销就至少 32 字节，再算上哈希表内部的扩容冗余，总内存占用轻松突破 500MB 大关。这可不是个小数目。
但换用 BITFIELD 或 SETBIT 来实现同样的功能，情况就大不相同了。存储一千万个签到状态，理论上只需要大约 1.25MB 内存。原因很简单：它的本质是一个连续的位数组，一千万个 bit 换算过来就是 1.25MB。这不仅仅是“能存”，关键在于 Redis 在底层为 Bitmaps 做了优化。
当位图中间出现大段连续的 0（比如大量用户未签到）或有规律重复的数据时，Redis 会自动将其转换为 RLE（行程长度编码）格式存储。在实际的稀疏签到场景中，这种压缩机制能让内存占用再降低 60% 到 90%，效果非常显著。
当然，要想充分发挥这个优势，有几个细节必须注意：
- 偏移量必须用数字：务必使用数值型的
user_id作为偏移量（offset）。如果使用字符串 ID，就得先查映射表，不仅失去了原子性操作的优势，空间效率也大打折扣。 - 偏移量最好连续：建议偏移量从 0 开始连续编号（例如使用自增 ID 或做好分段映射）。要避免出现巨大的“空洞”——比如只在 offset=9999999 的位置置位，前面全是 0。空洞越大，RLE 压缩的效果就越差，甚至可能退化为原始的 raw 存储格式。
- 控制单个位图大小：单个 Bitmap 的大小最好控制在 5000 万 bit（约 6MB）以内。如果位图过大，执行
BITCOUNT这类全量统计操作时，可能会阻塞 Redis 的主线程，影响服务响应。
怎么安全地把现有 Set 迁移到 Bitmaps？
直接从线上删除 SET 再重新写入 Bitmap，是一种高风险操作。迁移期间新的签到数据会丢失，而且整个过程无法原子化回滚。更稳妥的做法是采用“双写 + 渐进式切换”的策略：
- 并行双写：在上线前，先创建一个新的 bitmap key，例如
sign:20240501:bitmap。此后所有新的签到请求，都需要同时执行两条命令：SETBIT sign:20240501:bitmap {uid} 1以及原有的SADD sign:20240501:set {uid}。 - 后台迁移：通过一个后台任务，分批读取旧 Set 中的数据。使用
SSCAN命令游标分页，每次获取一批（比如1000个） user_id。然后，通过BITFIELD sign:20240501:bitmap SET u1 {offset} 1命令批量写入到位图中（注意这里的 offset 需要是映射后的数字）。 - 切换与清理：确认数据迁移无误后，将业务的读取逻辑切换到 Bitmap，使用
BITFIELD ... GET u1 {uid}来查询。随后停止向旧 Set 写入数据。最终，择机删除旧的 Set key。
⚠️ 这个过程中有几个容易踩坑的地方：面对大数据量，绝对不要使用会阻塞的 SMEMBERS 命令，务必改用 SSCAN。使用 BITFIELD 时，u1 表示无符号的 1 位整数，千万别错写成 i1（有符号）或 u8（这会占用 1 个字节，完全失去了位图压缩的意义）。
为什么开了压缩还是内存没降？
有时候，明明启用了位图，但用 MEMORY USAGE 命令查看，发现内存占用和理论的 bit 数差不多，压缩似乎没生效。这通常是由以下几个原因导致的：
- 偏移量非数字：如果尝试用字符串（如
"u1001"）作为 offset，Redis 可能会拒绝写入，或者在某些客户端驱动下静默失败，数据实际上并没有存进去。 - 数据过于稀疏：写入的 offset 分布极度离散（例如只写了 1, 1000000, 2000000 这几个点），中间存在大量空洞。这种情况下，RLE 压缩算法无从下手，会退化为原始的 raw 格式存储。
- Key 被污染：如果不小心对同一个 bitmap key 执行了
APPEND、SETRANGE等非位图操作命令，可能导致底层编码类型变得混杂，压缩特性随之失效。 - Redis 版本过低：位图的 RLE 压缩功能是从 Redis 4.0 版本开始引入的。如果版本低于 4.0，则无法享受此优化，最多只能依赖
ziplist编码节省有限的内存。
如何验证？可以使用 DEBUG OBJECT your_bitmap_key 命令查看 encoding 属性。如果显示为 raw 或 embstr，就说明压缩没起作用。理想状态下，它应该显示为 quicklist（其内部采用了 RLE 编码的 listpack 结构）。
BITFIELD 多操作原子性够用吗？
BITFIELD 命令本身是原子的，在一次调用中执行多个 GET 或 SET 子操作时，不会被其他客户端的命令打断。但是，这并不完全等同于一个事务，有几个关键点需要了解：
- 子操作失败不影响整体：如果某个子操作越界（例如 offset 超出了当前位图的长度），Redis 的默认行为是用 0 填充并继续执行后续操作，而不会报错或中断整个命令。这很容易掩盖程序中的逻辑错误。
- 缺乏回滚机制：假如一次
BITFIELD调用中前 3 个SET都成功了，但第 4 个失败了，前面已经生效的操作是无法自动撤回的。 - 返回值处理需谨慎：命令的返回值是一个数组，严格对应每个子操作的执行结果。但有些客户端库（例如某些 Python 的 SDK）可能会自动将多返回值解包成单个值，导致开发者误判。
因此，在实际应用中，对于简单的签到场景，直接使用 SETBIT 更为简单可靠。而 BITFIELD 的强大之处在于处理批量或复杂的位操作，例如统计用户本周的连续签到天数，结合 INCRBY 和掩码来提取、更新特定的位字段。不过，务必在设计初期就规划好每一位的语义，因为后期修改的成本会非常高。
说到底，使用 Bitmaps 真正的挑战往往不在于语法本身，而在于偏移量的设计和对数据生命周期的管理。一个没有对齐的 ID 映射方案，或者一段被遗忘的旧迁移脚本，都足以让位图压缩的优势荡然无存。
