去年我给社区App做签到功能产品经理张嘴就要“连续签到、累计签到、当月活跃用户数”。我一开始老老实实用Hash存每个用户的签到日期结果一个月跑下来几十万用户的签到记录在Redis里堆了几百MB查一次连续签到还要把所有日期捞出来在业务层循环判断慢得离谱。后来我把所有签到状态换成Redis的Bitmap内存直接砍到原来的十分之一连续签到统计从秒级变成微秒级。这篇就把我研究Redis Bitmap的完整笔记整理出来从底层原理、命令细节到生产环境里的各种坑一次讲清楚适合正在用Redis做统计类需求、或者准备面试数据结构的同学参考。顺便先做个名词分流如果你搜Bitmap搜到的是Windows磁盘修复工具里的“bitmap中有标记为已使用的未用簇”那是NTFS文件系统管理磁盘簇用的位图表和Redis的Bitmap只是中文翻译撞车底层思路有点像但完全不是一回事。本文讨论的是Redis里基于字符串类型实现的那套位操作数据结构。1. 先搞明白Bitmap在Redis里的真实身份1.1 位、字节和二进制安全的底层账很多教程一上来就甩命令但我觉得先弄懂“为什么能这么玩”更重要。计算机里最小的存储单位是位bit一个位只能存0或18个位组成一个字节byte所以1字节能表示256种状态。Redis的Bitmap本质上就是一条value为字符串的key只不过我们不再把字符串当成“一串字符”来读而是把它当成“一串位”来操作第1位、第2位、第3位……每一位都可以独立置0或置1。这里的关键在于Redis的字符串类型是二进制安全的。意思是它的底层结构并不会用某个特殊字符标记字符串结尾你写进去的每个字节都会被原样保存包括不可见的二进制数据。这个特性极其重要因为Bitmap里存的是一堆“非人类可读”的二进制数值如果中间混进了一个\0就截断那整个位图就废了。Redis用SDS简单动态字符串结构存value长度是单独记录的所以能完整承载任意二进制数据这才有了Bitmap存在的根基。1.2 为什么Redis不专门建一种Bitmap类型Redis官网把数据结构的清单列得很长String、Hash、List、Set、ZSet、Stream、HyperLogLog……但Bitmap并没有被单列为一种数据类型。原因是没必要——BitMap的所有命令本质上都建立在字符串的随机读写之上。当你在Redis里敲SETBIT时它先按key找到那个字符串再定位到字符串中字节数组的具体位置把这个字节里某一位进行修改。这种设计的聪明之处在于它复用了字符串的一切基础能力包括过期时间、持久化、主从复制、内存淘汰策略。你可以给一个Bitmap的key设置TTL就像给普通字符串设置TTL一样RDB和AOF备份时也只需要按字符串来处理完全不用为新的数据类型额外写一套底层存储逻辑。代价就是学习上有那么点绕——你在Redis Desktop Manager这类可视化客户端里看一个Bitmap的key类型那一栏显示的永远都是stringvalue则是一堆乱码一样的二进制字节我第一次看到时也愣了一下。1.3 一道能挂黑板上的容量对比题面试里关于数据结构Bitmap被问得最多的问题之一就是怎么用最少内存记录一亿个用户的在线状态常规思路是每个用户用一个字段比如online:10001 - 1存字符串“1”占1字节一亿用户就是100MB起步这还没算key本身的元数据开销。但用Bitmap方案完全不同给每个用户分配一个固定的bit位置比如用户ID就是偏移量在线置1离线置0。一亿个用户只需要一亿个位除以8就是12.5MB。如果是两亿用户呢25MB。内存开销与用户量严格线性挂钩而且单位是“位”而不是“字节”这账一算谁都能看出差距。这就是Bitmap的第一性原理当业务逻辑只是“一个对象有没有某种状态”这种布尔判断时用整数去存是浪费用字符串去存更是浪费一位一位地存才是最省空间的方案。2. 核心命令实战边敲边记重点2.1 SETBIT 与 GETBIT最基础的读写先把两个最常用的命令讲透。SETBIT key offset value GETBIT key offsetSETBIT把指定偏移量上的位设置成0或1GETBIT则是读取指定偏移量上的位。偏移量从0开始计数也就是说第0位是第一个bit。命令执行时如果offset对应的位之前不存在比如给了个很大的偏移量而key当前长度很短Redis会自动把中间的位全部补0再设置目标位返回的是设置之前该位原有的值这个返回值可以用来做幂等判断。实际操练一下127.0.0.1:6379 SETBIT online:20240501 10001 1 (integer) 0 127.0.0.1:6379 GETBIT online:20240501 10001 (integer) 1 127.0.0.1:6379 GETBIT online:20240501 10002 (integer) 0用户10001在线10002不在线一目了然。这里有个新手很容易踩的误区value参数只能传0或1传其他数值会直接报错。而且offset虽然可以很大但不能超过2^32-1原因后面讲容量时再细说。2.2 BITCOUNT 与 BITPOS统计与定位光能读写位还不够业务里最常问的是“有多少个1”。这就是BITCOUNT的活BITCOUNT key [start end [BYTE|BIT]]BITCOUNT统计整个位图中值为1的位数量。注意start和end默认是字节索引不是位索引。比如BITCOUNT online:20240501 1 1统计的是第1个字节也就是第8位到第15位里1的数量而不是统计第1位。Redis 7.0之后可以通过显式加BIT参数来按位偏移比如BITCOUNT online:20240501 0 7 BIT就是统计前8位。BITPOS则是反向操作找出第一个被设置为0或1的位的位置。BITPOS key bit [start [end [BYTE|BIT]]]比如BITPOS online:20240501 0返回第一个为0的位偏移量如果整张位图全是1就返回-1。这个命令在实现“连续签到中断点检测”时非常有用后面场景部分我会展示具体用法。2.3 BITOP并集、交集、差异一次算完BITOP是组合拳可以对多个key做位运算结果写到指定目标key里BITOP operation destkey key [key ...]operation支持四种AND与、OR或、XOR异或、NOT非。最常见的用法是做多天在线状态合并每天一个key某用户当天在线就把对应位设1。想知道“这个月累计有多少用户上过线”把一个月30个key做一次OR结果里位为1的就是本月活跃用户再BITCOUNT一下就是数量。想知道“连续N天都在线的用户”就把N天key做AND为1的就是全勤用户。NOT要注意只能传一个key传多个会报错而且它会把结果按“原字符串位取反”来算原key为0的位变成1原key为1的位变成0容易下意识算反。2.4 BITFIELD把位图当整数数组用BITFIELD是Redis 3.2引入的重量级命令它能对位图做子比特操作相当于把一个位图拆成一排小整数来处理。基本用法BITFIELD key GET type offset BITFIELD key SET type offset value BITFIELD key INCRBY type offset incrementtype的形式是i或u加位数比如u8表示8位无符号整数i16表示16位有符号整数。offset可以用普通位偏移量也可以用#前缀表示“按类型宽度对齐”比如GET u8 #5就是读取第5个u8整数相当于把位图当成一个u8数组来随机访问。INCRBY还能做原子自增配合OVERFLOW WRAP|SAT|FAIL控制溢出行为比如用SAT饱和模式计数器到255就不会再往上加防溢出十分方便。这段记忆有点抽象我一般用一个比喻普通SETBIT是“一行一行往表格里填Dota”BITFIELD则是“把这一整个表格切成定长的小格子每个格子直接当一个数字来加减乘除”。如果你需要在一个key里存几千个小于255的计数器用BITFIELD比用几千个字符串key省太多了。为了看得更清楚我把常用命令整理成一个速查表命令作用时间复杂度关键注意点SETBIT key offset value设置某一位为0或1O(1)offset最大2^32-1value只能0/1GETBIT key offset读取某一位O(1)越界返回0BITCOUNT key [start end]统计1的数量O(N)偏移单位默认是字节BITPOS key bit [start end]找第一个0或1的位置O(N)全为1时找0返回-1BITOP op destkey key...位运算合并O(N)NOT只能单个keyBITFIELD key GET/SET/INCRBY按子位宽读写整数O(1)支持u/i类型与#对齐3. 生产场景三个直接抄3.1 用户签到把第几天当偏移量签到功能是我最早落地Bitmap的地方也是我认为最典型的应用。设计上极其直白每个用户每个自然月一个keykey里bit的偏移量就是“这个月的第几天减1”。# 用户10086在2024年1月5日签到 SETBIT sign:202401:10086 4 1 # 用户10087在2024年1月5日签到 SETBIT sign:202401:10087 4 1 # 查询10086当月签到天数 BITCOUNT sign:202401:10086“当月签到天数”一个BITCOUNT就出来了“5号当天有多少人签到”则是把当天偏移量对应的位全部算一遍用累加逻辑或者如果你把全体用户签到也按日期建了索引key直接BITCOUNT即可。连续签到的判断稍微绕一点先取当前日期对应的偏移量day然后用BITPOS从前向后找第一个0的位置。# 从第0位开始找第一个0 BITPOS sign:202401:10086 0如果返回的位置大于等于day说明从1号到今天全是1连续签到天数就是day1如果返回位置是n说明从1号到n-1号连续签到n号断签那么到今天“正在持续的连续天数”就不是这个算法能直接解释的了需要配合当前日期做分段判断。生产环境里更常见的需求是“统计从今天开始往前连续签到几天”这个要把当前日期对应的位置当作区间终点用BITPOS配合起始偏移来倒推。实际写过一次就会明白核心思路就一句话用找0来识别断点用找1来确认在签。3.2 在线状态与日活分析一个用户一个位在线状态也是Bitmap的重头戏。做法和签到类似但key拆分维度不同每天一个key用户ID映射到位偏移量。比如用户ID是100012024年5月1日在线就执行SETBIT online:20240501 10001 1。当天任何时刻在线列表都能用这个key表达。要统计日活BITCOUNT online:20240501要统计周活、月活就用BITOP OR把多天key合并BITOP OR weekly_active online:20240501 online:20240502 ... online:20240507 BITCOUNT weekly_active要统计连续7天都在线的核心用户做ANDBITOP AND core_weekly online:20240501 ... online:20240507 BITCOUNT core_weekly这种思路最大的收益是原来日活统计要维护一个巨大的集合每天都要做去重现在去重交给位运算自动完成同一个用户即便一天在线100次也只是把同一个位重复置1天然去重。内存上哪怕你有1000万用户一天的在线位图也就1.25MB一个月合并一次也不会撑爆内存。3.3 布隆过滤器低成本去重的底层组件第三个场景稍微进阶一点是布隆过滤器。Bitmap常被用来做布隆过滤器的存储底座先准备一个长度为m位的位图写入数据时用k个哈希函数算出k个位置把这k个位全部置1查询时同样计算k个位置只要有一个位是0就确定数据不存在。Redis里实现方式很简单就靠SETBIT和GETBIT堆出来。参数上有现成公式辅助设计假设要放n个元素、期望误判率p那么位图长度m ≈ -n * ln p / (ln 2)^2哈希函数数量k ≈ m/n * ln2。举个例子100万个URL去重期望误判率1%算下来m大概是958万位约1.2MBk取7。用Bitmap做底座加上几个哈希函数一套简易布隆过滤器几十行代码就能跑起来既不用引入独立中间件也不占用多少内存。有个坑需要提前说简单布隆过滤器不支持删除。如果业务要求删除某个元素可以用Counting Bloom Filter的变体把每个位扩展成一个小计数器删除时对应计数器减1。这时候上面讲的BITFIELD就能派上用场——把位图每4位或8位当成一个计数器来用加一减一都能原子操作。4. 容量、性能和大key治理4.1 为什么上限是512MB和2^32位Redis单个字符串key的value最大是512MB这个限制直接框死了Bitmap的规模。512MB换算成位就是512 * 1024 * 1024 * 8 4,294,967,296位正好是2的32次方。所以SETBIT的offset范围才是0到2^32-1。这不是随意定的每一位的偏移量本身要用无符号32位整数表示加上Redis内部对字符串大小的硬限制两个条件一撞就撞出了这个上限。理解这个上限对架构设计很有用。假如你的用户规模超过42亿单个Bitmap就装不下了必须分片。但大部分业务根本到不了这个量级所以这个限制在绝大多数场景只是面试考点。真正要命的是另一个更隐蔽的问题不要在稀疏数据上乱用高偏移量。如果你只有1万个用户偏要把用户ID加一个亿再当offsetRedis会为这个key直接分配一个亿位约12.5MB的字符串。内存被一次性拉满RDB持久化、主从复制的压力也会跟着上来。4.2 BITCOUNT快在哪性能实测与替代方案很多人担心Bitmap统计1的数量要遍历整个位图慢不慢实测下来几MB以内的位图做一次BITCOUNT都是微秒到百微秒级别完全够用。原因在于Redis源码里用了SWAR算法和查表法结合的方式每次不是数一个位而是把若干字节一次性读出来通过位运算技巧在几个指令内算出这批字节里1的个数而不是逐位循环。这种优化在密集的位运算场景下效果极其明显。如果你要做的事情是“遍历所有在线的用户ID”那就需要另一种思路先GET整个字符串在业务层逐字节扫描对每个非0字节再逐位找出1的位置。这比在Redis里循环调GETBIT高效得多因为省去了大量的网络往返。我实际写过一个导出工具先GETBIT循环5万次耗时几百毫秒改成GET后本地解析整个导出压缩到十几毫秒。两者差了一个量级所以能用一次GET解决的就别用一万次GETBIT。4.3 大key拆分分片、对齐与PipelineBitmap用久了最怕的就是一个key越来越大。一天在线用户1000万一个key才1.25MB看似不大但如果你把一年的在线数据都塞进一个key再叠加各种BITOP那问题的性质就变了。单个key过大在Redis里叫大key风险RDB生成时fork可能卡顿AOF重写内存开销上升主从同步时网络传输一个大字符串也容易拖慢。业界经验值是单个string超过10MB就明显该拆了我的习惯是在1MB左右就评估一次。拆分思路无外乎两种。第一种按时间拆每天一个key查询时用BITOP合并这也是前文一直在用的模式。第二种按用户分片把用户ID哈希取模分成多个key比如online:shard0、online:shard1查询时把对应分片合并。分片之后原先针对整个用户集合的统计变成了N个子位图的统计再加总逻辑复杂一点但内存和操作粒度都好控制。批量写入时可以配合Pipeline把几万个SETBIT打包成一次网络请求发送吞吐量立刻上一个台阶。5. 踩坑实录这些问题我全遇过5.1 BITCOUNT的start/end是字节不是位这是我在生产环境踩到的第一个Bitmap坑。当时做运营报表想统计某一天在线用户数在前100个用户里的分布随手写了BITCOUNT online:20240501 0 99结果和另一个统计口径对不上排查半天才发现start和end默认是字节索引0到99是前100个字节800位而不是前100个位。把它改成BITCOUNT online:20240501 0 99 BIT之后结果才和预想一致。这个问题在新手期出现的频率极高而且报错不会提示只有结果对不上你才会发现。5.2 偏移量越界与隐式补零的内存刺客SETBIT的offset超出2^32-1会直接报ERR这个还好错误信息清晰。更隐蔽的是“中间自动补0”带来的内存膨胀。有次巡检发现某个位图key的值莫名其妙涨到了几十MB查了代码才发现有个接口在写入时把用户ID和某个大数做了拼接导致偏移量比实际用户ID大了几个数量级Redis为了设置那一个位默默开辟了几十MB的中间空间。这个设计本意是方便随机访问但如果你乱用offset它就成了内存刺客。规则很简单offset的最大值永远不要明显超过有效业务ID的上限。5.3 BITOP的结果长度按最长key算短的补0在做多天AND统计时我发现过一个诡异现象某天只有少量用户出现那天生成的位图key因为没人SETBIT过高偏移量长度比其他天短很多。BITOP执行时结果长度等于参与运算的最长key的长度短的key缺失部分按0处理。这本来没问题但如果你之后用BITPOS去找这个结果里的0不同人可能得到不同解释。所以做BITOP前尽量保证所有参与key的位图长度一致或者在合并后对结果做一次规范化处理。多天合并这类使用场景最好在写入时设定统一的位图长度策略。5.4 用户ID跳号稀疏位图的内存账把用户ID直接当offset要求用户ID相对连续。如果业务里用户ID是自增的但中间大量删除跳号或者用户ID是一个雪花算法生成的18位大数直接当offset会让位图变得极度稀疏。一个ID为2^60的用户塞进去直接把单个key撑爆。当初我在迁移一个老系统时踩过用户量只有30万但ID已经涨到1亿一不做映射直接SETBIT内存直接爆掉。解决办法要么给业务维护一份“用户ID到连续序号”的映射表写入和查询时先翻译要么按ID范围分片到不同key让每个key内部的ID相对集中。没有银弹但必须在设计阶段就想清楚。这些年用下来Bitmap给我的整体感受是它不是一个“花哨”的数据结构而是一个极其朴素的省内存工具。你自己用二进制数位表示一个状态集合的想法其实任何语言都能实现但Redis把它做成了原子操作、带持久化、支持分布式访问的通用能力这才是它真正值钱的地方。我个人现在最常用的其实是BITFIELD那条命令很多需要一堆小计数器的需求用它一个key就能优雅解决后续如果有机会我再单独写一篇它的进阶玩法。