Redis位图判断数据存在方法

Redis位图通过SETBIT和GETBIT实现超高效（O(1)时间、极低内存）的二值存在性判断，特别适合用户签到、设备在线、风控黑名单等海量稀疏场景，但必须严格保证ID到整数偏移量的全局映射一致性；它不支持三态语义（未设置位默认读作0），严禁用BITCOUNT替代存在检查，使用BITOP做多条件交集时需预先确保所有源key存在，而真实内存占用应以STRLEN为准而非理论最大值——用对了是空间与性能的利器，用错一点，整个逻辑就悄然失效。

用 SETBIT 和 GETBIT 做存在性判断最直接

Redis 位图（Bitmap）本质是字符串的底层操作，SETBIT 把某一位设为 1，GETBIT 查某一位是否为 1——这比存完整 key 更省空间，也比用 EXISTS 查 key 是否存在更快（尤其在海量稀疏数据场景下）。但注意：位图不自动扩容，SETBIT 写入超出当前长度的位置会自动补零，而 GETBIT 查询未写过的位默认返回 0。

• 适合判断“某 ID 是否被标记过”，比如用户签到、设备在线状态、风控黑名单 ID
• 不要用它查“值是多少”，位图只存 0/1，没有中间态
• SETBIT user:sign:20240501 1 中 是整数偏移量，不是字符串 ID；如果原始 ID 是字符串，得先映射成唯一递增整数（比如用 INCR 或预分配 ID 段）
• 单个字符串最大支持 2³² 位（约 512MB），超了会报错 ERR bit offset is not an integer or out of range

别把 BITCOUNT 当存在性检查用

BITCOUNT 统计 1 的个数，常被误用来“间接判断是否存在”——比如先 BITCOUNT 再看是否 > 0。这多了一次全量扫描，完全没必要。只要确认某一位是 1，就代表存在；查一位用 GETBIT 是 O(1)，查全量是 O(N)。

• 错误做法：BITCOUNT user:sign:20240501 然后判断结果是否非零
• 正确做法：GETBIT user:sign:20240501 ，返回 1 就存在，0 就不存在（注意：0 不代表“明确不存在”，而是“没被设过 1”）
• 如果业务要求区分“从未设置”和“显式设为 0”，位图做不到——它没有三态，只有 0 和 1，且未设置位默认读作 0

用 BITOP AND 做交集判断时小心空 key

想判断“用户是否在多个条件集合中都存在”，比如“既签到又完成实名又通过风控”，常用 BITOP AND dest k1 k2 k3 得到共同位，再 GETBIT dest uid。但只要任意一个源 key 不存在，BITOP 会把它当作全 0 字符串参与运算，结果可能全 0，导致误判。

• 必须确保所有参与 BITOP 的 key 都已存在（哪怕只是空字符串），否则逻辑崩坏
• 安全做法：对每个 key 先 EXISTS，或统一用 SETNX 初始化空位图（SETNX user:realname:20240501 ""）
• BITOP 结果写入新 key，不能原地操作；目标 key 若已存在，会被覆盖
• 大位图做 BITOP 有 CPU 开销，线上慎用于高频实时判断，更适合离线或低频聚合

位图内存不等于实际占用，STRLEN 才是真实字节数

位图的“大小”容易误解：GETBIT 支持最大偏移 2³²−1，但不代表你真要占 512MB。Redis 按需分配底层字符串空间，STRLEN 返回的是当前实际字节数。比如只设了第 100 万位，STRLEN 可能只有 125001 字节左右（1000000 ÷ 8 + 1）。

• 监控位图膨胀要用 STRLEN，不是靠偏移量估算
• 用 DEBUG OBJECT 看编码类型，确认是 raw 还是 embstr（小位图会优化存储）
• 删除旧位图用 DEL，别用 SET 覆盖空字符串——后者仍保留 key，且可能触发 RDB/AOF 写入开销
• 位图不可压缩，LZF 压缩对纯位图效果差，别指望靠配置节省空间

实际用起来最易忽略的，是 ID 到位偏移的映射一致性——一旦某处用哈希转整数，另一处用自增 ID，存在性判断就彻底失效。位图本身很稳，出问题几乎都在外面那层映射上。

终于介绍完啦！小伙伴们，这篇关于《Redis位图判断数据存在方法》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布数据库相关知识，快来关注吧！