Redis如何利用位图快速判断数据存在性

用 SETBIT 和 GETBIT 做存在性判断最直接SETBIT 设定位为 1GETBIT 查该位是否为 1O(1) 时间、极省空间不可用 BITCOUNT 替代不支持三态需确保 ID 到偏移量映射一致。用 SETBIT 和 GETBIT 做存在性判断最直接Redis 位图Bitmap本质是字符串的底层操作SETBIT 把某一位设为 1GETBIT 查某一位是否为 1——这比存完整 key 更省空间也比用 EXISTS 查 key 是否存在更快尤其在海量稀疏数据场景下。但注意位图不自动扩容SETBIT 写入超出当前长度的位置会自动补零而 GETBIT 查询未写过的位默认返回 0。适合判断“某 ID 是否被标记过”比如用户签到、设备在线状态、风控黑名单 ID不要用它查“值是多少”位图只存 0/1没有中间态SETBIT user:sign:20240501 uid 1 中 uid 是整数偏移量不是字符串 ID如果原始 ID 是字符串得先映射成唯一递增整数比如用 INCR 或预分配 ID 段单个字符串最大支持 232 位约 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 uid返回 1 就存在0 就不存在注意0 不代表“明确不存在”而是“没被设过 1”如果业务要求区分“从未设置”和“显式设为 0”位图做不到——它没有三态只有 0 和 1且未设置位默认读作 0用 BITOP AND 做交集判断时小心空 key想判断“用户是否在多个条件集合中都存在”比如“既签到又完成实名又通过风控”常用 BITOP AND dest k1 k2 k3 得到共同位再 GETBIT dest uid。但只要任意一个源 key 不存在BITOP 会把它当作全 0 字符串参与运算结果可能全 0导致误判。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。