Redis Bitmap实战指南：内存原理、核心命令与签到/布隆过滤器应用

你接手过这样一个需求吗运营说“我要实时看今天有多少用户登录了”然后你反手掏出Redis把登录用户的ID一个SADD塞进Set里。早期的我也是这么干的直到某次压测时看着内存曲线往上蹿才彻底想明白——一百万条用户ID用Set存轻松几十MB起步而用Redis的Bitmap只需要125KB上下。这篇专门聊聊Redis里的Bitmap底层到底怎么存、五个核心命令怎么用、签到系统和布隆过滤器怎么落地以及我在真实项目里踩过的位序、大Key、稀疏分布这些坑。不管你是刚学Redis的萌新还是已经在生产环境用Redis的老手这组内容都能直接抄作业。网上搜“Bitmap”时经常跳出来一堆Windows分区工具的报错什么“C盘bitmap中有标记为已使用的未用簇”那是NTFS文件系统的$Bitmap元文件在报一致性错误跟Redis的位数组完全是两码事。别被名字带偏Redis的Bitmap本质就是普通字符串只是一条条按位来读写的命令把它变成了一张紧凑的位图。1. 先看它能帮你省多少内存一个场景对比1.1 用Set存状态内存账单有多离谱假设你有100万在线用户把登录用户的ID全部塞进Set。如果是数字ID且数量不大Redis会用intset编码每个元素8字节但Set底层还有dictEntry的指针、SDS对象头、内存分配对齐实际算下来每个用户大概30到40字节百万用户就是30到40MB。一旦ID变成手机号、UUID这种字符串每个元素还要多出SDS头和内容本身的空间破100MB是轻轻松松的事。这还只是“在线名单”一个状态。如果叠加“是否完成新手任务”、“是否领取过奖励”、“是否已读某条公告”这十几个布尔状态按老办法每个状态一个Set内存就彻底失控了。1.2 Bitmap的核心价值用bit位换存储Bitmap解决这个问题的方式非常“抠门”既然我只关心“这个用户在不在”那每个用户只需要一个开关。有置1没有置0。从0号用户开始按顺序排一亿个用户就是一亿个bit换算下来约12MB。同样一亿用户用Set存即便按intset算也奔着300到400MB去了几十倍的差异就是这么来的。这种“用一个位表达一个状态”的思路说穿了就是拿空间换时间再拿位粒度换空间。Redis提供了一组直接操作二进制位的命令你不用自己去解析字节SETBIT、GETBIT、BITCOUNT这些命令已经把位操作封装好了。1.3 先泼盆冷水Bitmap不一定总是省很多教程只讲Bitmap省内存却没人提“稀疏分布”这个反例。Bitmap的底层是连续字节数组Redis在第一次设置某个高offset时会直接把字符串扩展到对应长度。如果10万个用户ID散落在5000万的位置上即使只设置了10个bit底层字符串也会被撑到6MB左右而Set只占几百字节。所以Bitmap不是万能的。它适合“ID比较稠密”或者“你能做好分桶”的业务不适合拿超大随机数当offset乱用。什么时候该换Set、什么时候该分桶我放到最后一章细说。2. 底层原理与五个核心命令2.1 底层存储其实还是一个SDS字符串在执行SETBIT之前最好先知道它背后就是一个普通字符串。Redis没有单独的位图结构SETBIT key offset 1等于把字符串里第floor(offset/8)个字节的第(offset%8)位改成1。Redis在这里偷了个懒第一次设置高位offset时它不会先清空中间所有字节而是直接把SDS字符串扩展到位偏移所在的字节扩展出来的空间默认全是0。所以STRLEN查到的就是这个位图实际占用的字节数。比如offset是1001落在第125个字节字符串长度就变成126。字节内的位序是从最高有效位开始算的。offset 0落在字节的最高位也就是二进制1000_0000的第一位offset 7才落在字节的最低位。这个和很多人直觉里的“第一位是最低位”正好相反新手调位序调到头秃的根源基本都在这里。2.2 SETBIT与GETBIT最基础的位读写SETBIT语法是SETBIT key offset valuevalue只能是0或1返回值是旧值。GETBIT语法是GETBIT key offset返回该位当前值。实操一下127.0.0.1:6379 SETBIT online:20250625 1001 1 (integer) 0 127.0.0.1:6379 GETBIT online:20250625 1001 (integer) 1 127.0.0.1:6379 STRLEN online:20250625 (integer) 126offset的合法上限是2^32-1因为字符串最大512MB512MB乘以8正好是2^32个bit。超出会报ERR bit offset is not an integer or out of range。GETBIT有个容易误用的点读超出字符串长度的offset会返回0不会报错。所以别用GETBIT判断key是否存在判断key存在与否要用EXISTS。另外SETBIT返回的是旧值如果旧值也是1你看到返回值是1不代表“设置失败”只代表这一位之前就是1。2.3 BITCOUNT与BITPOS统计和定位BITCOUNT统计位图中1的个数语法是BITCOUNT key [start end]start和end是字节下标不是bit下标。很多人在签到场景里想统计前31天写BITCOUNT key 0 31结果统计到了第31个字节也就是248位直接多算出去。31个bit只占4个字节正确写法是BITCOUNT key 0 3。BITPOS找第一个0或1的位置语法是BITPOS key bit [start end]。比如想知道一个月的签到里第一个没签到的日子就可以从offset0开始找第一个0。空串和全零串查找1会返回-1代码里要额外处理。这里提醒一句BITCOUNT和BITPOS一旦用了范围参数边界行为容易折腾人。生产环境建议先用STRLEN量好字节长度再配合范围切片别凭感觉写。2.4 BITOP与BITFIELD位运算和批量操作BITOP支持AND、OR、XOR、NOT主要用来合并多个位图。典型场景是把连续7天的在线用户合并成“7日活跃用户”127.0.0.1:6379 SETBIT day1 5 1 127.0.0.1:6379 SETBIT day2 5 1 127.0.0.1:6379 BITOP AND online_7d day1 day2 (integer) 1这里有几个细节容易踩不同长度key做位运算时短key缺失的位按0算结果长度以最长key为准。AND时多出来的部分全变0OR时多出来的部分保留原值。BITOP是O(N)操作N是最长key的字节数跨月合并大key时要注意阻塞风险。BITFIELD是3.2版本引入的进阶命令把一整段连续位拿出来或写进去是批量操作的大杀器127.0.0.1:6379 BITFIELD sign:10001:202506 GET u31 0 (integer) 1852730990 127.0.0.1:6379 BITFIELD sign:10001:202506 SET u1 5 1 (integer) 1GET u31 0表示从bit0开始取31个位组成一个无符号整数。注意这个整数的位序是反的bit0代表第1天落在整数最高位不是最低位。解析二进制时必须把位序交换一下或者直接用位运算定位到第30-j位否则你会发现签到天数全部错位。这个坑教程里很少提但客户端代码写错就是唯一的大坑。3. 实战案例一月度签到系统的完整落地3.1 方案设计key怎么定offset怎么算签到功能大家都不陌生但真正动手时会发现设计上有个岔路口按用户建key还是按天建key我的建议是面向个人查询的签到场景按用户建key每个用户每月一个keykey user:sign:{userId}:{202506}签到第n天执行SETBIT key n-1 1因为offset从0开始第1天对应0第15天对应14这个换算关系要刻在脑子里。按用户建key的好处是查“某人某月签到状态”时一次BITFIELD就能把整月31个bit拉回来业务逻辑里可以做连续签到、补签判断、月度热力图几十个命令瞬间变成一个命令。全局统计“全网每天有多少人签到”这种场景反而更适合按天建key把userId当offset每天一个key配合BITCOUNT快速得到当日签到总数。3.2 核心操作组合判断、统计、连续签到判断当天是否已签GETBIT user:sign:10001:202506 14返回1就是签了0就是没签。统计本月一共签了多少天BITCOUNT user:sign:10001:202506批量取月度位图在应用层做连续签到计算BITFIELD user:sign:10001:202506 GET u31 0拿到一个整数mask后连续签到可以写成这样的伪代码def continuous_sign(mask, today_idx): # mask 是 BITFIELD GET u31 0 的返回值 # 第 j 天0起始对应 mask 的第 (30 - j) 位 cnt 0 for j in range(today_idx, -1, -1): if (mask (30 - j)) 1: cnt 1 else: break return cnt再次强调那件事BITFIELD GET u31 0返回的值bit0位于最高位。判断第j天要用30-j不是j。位序搞反之后连续签到永远算成0或1而且很难排查。补签就简单了SETBIT user:sign:10001:202506 3 1过期清理建议用EXPIRE user:sign:10001:202506 2592000保留30天。线上我一般保留60天因为连续签到活动最长跨三个月再久的历史没有查询价值白白占用内存。3.3 内存与性能测算一亿用户到底占多大地方按天建全局key的方案下一亿用户一天约12MB一个月31天累计约372MB。看起来不少但对比用Hash存用户ID至少几百MB起步还是省得多。按用户建key的方案这里有一个隐藏炸弹一亿用户就是1亿个key每个key内部可能只占4个字节但Redis对象头、dictEntry、SDS头这些固定开销每个key大约要几十字节总开销可能会到几十GB。所以用户量过千万时别用“一用户一key”做全局统计改成“按天分片、用户ID当offset”更划算。个人签到查询场景如果实在绕不开也要分桶控制key数量并给key设置合理的TTL。我在真实项目里的折中方案是用户量小的活动用“一用户一月一key”图的是开发简单、查询直接日活过千万的常驻功能一律改成“按天分片的全局位图 应用层聚合”配合定时任务把时间久远的天级key定期过期。4. 实战案例二用Bitmap手写一个轻量布隆过滤器4.1 为什么需要它原理是什么缓存穿透、URL去重、黑名单预判这些场景核心诉求是“这个值不可能存在就别去查下游了。”但直接存全量数据太贵所以需要一个“可能存在/肯定不存在”的概率结构。布隆过滤器的原理是用k个哈希函数把同一个元素映射到位数组的k个位置并置1。查询时只要有一个位置是0就能断定元素肯定不存在全部为1时只能说“可能存在”。代价是误判收益是空间被压到极小和Bitmap简直是天作之合。4.2 参数计算1000万URL需要多大的位数组布隆过滤器有两个核心公式 m -n * ln(p) / (ln2)^2 k m / n * ln2n是预期元素数量p是容忍的误判率。假设有1000万URL要做去重容忍1%误判率m约等于958万个bit换算下来约1.2MB。k约等于7也就是每个元素要做7次置位、7次查询。如果误判率要压到0.1%m约1440万个bit约1.8MBk约等于10。这个增大速度比想象中慢所以1%误判率对绝大多数业务都够用。4.3 在Redis里的落地方式最简单的落地方式客户端算出k个offset用pipeline批量置位def bloom_add(redis, bloom_key, offset_list): p redis.pipeline() for off in offset_list: p.setbit(bloom_key, off, 1) p.execute() def maybe_exists(redis, bloom_key, offset_list): for off in offset_list: if redis.getbit(bloom_key, off) 0: return False return True如果想保证原子性可以把k次setbit封装到一个Lua脚本里。命令级实现不复杂核心就是循环调用setbit/getbit。布隆过滤器有个天然限制不能删除元素。置1的位可能是多个元素共享的删一个会把其他元素的痕迹也抹掉。所以需要删除场景时要么定期重建整个过滤器要么用带计数的布隆过滤器变体别想着按元素清位。哈希函数选择上MurmurHash、FNV-1a这类分布均匀的算法都行千万别直接用简单的取模字符串hash冲突多了误判率会明显上升。5. 性能隐患与常见问题排查5.1 大Key失控的三个征兆Bitmap最容易出事的不是单条命令慢而是悄悄长成大Key。一个全局在线位图如果offset已经到5亿Redis就会分配62.5MB的字符串任何一次BITCOUNT、BITOP都可能造成实例阻塞。排查命令很直接redis-cli --bigkeys --pattern online:*看到字符串类型且bytes很大的key就要警惕。解决思路是分桶把ID除以桶大小得到分片keyID取余当offset。比如每1000万一桶内存约1.2MB还能用MGET批量读取多个桶。大Key的另一个隐蔽征兆是过期失效很慢。位图很大时DEL一个过期key也可能卡一下所以线上要避免创建超级大的位图。5.2 位序与偏移最容易踩的三个坑第一个坑是offset从0开始。第1天对应0而不是1很多业务代码写SETBIT key 1 1导致第2天被标记排查半天才发现。第二个坑是BITCOUNT范围按字节。想统计前31天却写了0 31直接统计到248位人多算了不止一倍。第三个坑是BITFIELD位序反转。解析u31整数时没有做交换导致所有签到判断全反。这个坑最隐蔽因为数据“看起来”有值只是对不上。还有一个容易被忽略的坑SETBIT返回的是旧值。如果要实现“设置成功且之前没设置过”的幂等逻辑只看返回值会误判得配合GETBIT或者用返回值0来判定。5.3 选型判断Bitmap、Set、HyperLogLog各管哪一段这几兄弟各有所长不是谁替代谁的关系Set管名单适合需要遍历成员、随时踢人的在线列表。Bitmap管开关适合快速判断某个ID在不在、精确统计总人数、跨天做位运算合并。HyperLogLog管估算日活这种允许1%左右误差的指标用固定12KB内存算千万级独立用户性价比无敌。一句话总结要精确、要遍历选Set要精确、要省内存、要位运算选Bitmap能接受误差、只想要个数量级选HyperLogLog。选型速查表需求推荐结构理由在线名单且需要遍历踢人Set天然支持SMEMBERS、SREM只看总数、允许误差HyperLogLog12KB搞定千万级精确判断用户是否在线/签到BitmapO(1)定位内存极省多天活跃用户合并去重Bitmap BITOP一条命令解决跨天集合5.4 常见问题速查表我把线上遇过的坑汇总成一张表排查时直接对着看现象原因处理GETBIT一直返回0offset从1开始传了统一从0计数BITCOUNT结果偏多start/end按bit传了按字节位置传BITOP结果全是0参与运算的key长度不一致短key缺位补0统一初始化到同一offset长度BITFIELD解析的签到天数全反位序没做交换用30-j定位第j天设置超大offset后内存暴涨稀疏位图分桶或换Setredis-cli --bigkeys发现大key某天全局在线key过长按小时/天拆分并设置过期最后讲一个我自己的习惯凡是“一个对象配一组布尔开关”的需求我会下意识先想Bitmap凡是“要存完整对象属性”的需求Bitmap就不合适。工具没有高下关键看数据形态是不是连续稠密的位。这个判断做多了选型基本不会翻车。再补一个上线前的小建议把redis-cli --bigkeys当成日常巡检脚本跑起来顺手记一下STRLEN。Bitmap的优点是把内存压到极小但一旦失控它涨内存的速度比Set还快因为Redis一次分配就是整段字节。谁都不想凌晨被运维叫起来清一个6GB的位图对吧。