Redis的Bitmap并不是一种独立的数据类型，它的底层依赖字符串存储，只是把字符串中的每个字节拆成8个比特，通过偏移量来读写某一位。理解这一点非常重要，因为当偏移量很大时，Redis会在字符串末尾自动填充零字节，这直接影响内存占用。假设要记录用户ID为100000000的状态，就需要创建一个长度至少为100000001位的字符串，大约需要12.5MB。很多场景中，Bitmap的价值正是用连续比特数组表达海量布尔状态，让统计和筛选变得非常直接。
Bitmap适合表达只有两种状态的数据，比如签到未签到、在线离线、登录未登录、是否拥有某个权限等。它最明显的优势是节省内存：如果用一个集合保存一亿个用户ID，即便每个ID只按8字节计算，也需要约800MB；而用Bitmap记录一亿个布尔状态，只需要约12MB。另一个优势是位运算速度快，多个Bitmap之间可以直接进行与、或、异或、非运算，非常适合做连续签到、交集活跃等分析。但Bitmap也有明显短板，当数据非常稀疏时，位图可能为了少数几个1而分配大量连续内存，此时反而不如Set或HyperLogLog划算。
命令基础：从位读写到批量聚合
Bitmap的核心命令围绕着位偏移展开。SETBIT用来设置某个偏移量的值为0或1，GETBIT用来读取某个偏移量的值。偏移量从0开始，Redis会自动扩展字符串长度来容纳更大的偏移量。比如执行 SETBIT online 100 1，Redis会创建一个长度至少为101位的字符串，其中前100位默认为0，第101位被置为1。如果需要记录的是用户ID，通常直接用用户ID作为偏移量，这样每个用户只占一位。
除了单个位操作，Bitmap还提供批量统计能力。BITCOUNT可以统计指定范围或整个位图中1的个数，BITPOS可以查找第一个0或1所在的偏移位置。BITOP则支持多个Bitmap之间的与、或、异或、非运算，并将结果写入目标键。比如要求连续两天都签到的用户，可以对两天的签到位图执行 BITOP AND，结果位图中仍为1的位就代表两天都签到的用户。BITFIELD则进一步支持在一次请求中读取或修改多个连续位，适合权限位这种需要组合多个标志的场景。
下面代码展示了签到场景中常用的几个命令组合：
# 设置用户1001当天签到 SETBIT sign:20250601 1001 1 # 读取用户1001当天是否签到 GETBIT sign:20250601 1001 # 统计当天签到总人数 BITCOUNT sign:20250601 # 找到第一个已签到用户偏移量 BITPOS sign:20250601 1 # 计算连续两天都签到的用户 BITOP AND sign:202506:both sign:20250601 sign:20250602 # 使用BITFIELD一次读取前8位 BITFIELD sign:20250601 GET u8 0
这些命令的复杂度大多与偏移量和返回数据量相关，整体执行速度很快。需要注意的是，虽然Bitmap底层是字符串，但如果直接对同一个键使用普通字符串命令，可能会破坏位操作的语义。因此在实际项目中，最好把Bitmap键单独管理，避免与其他字符串数据混用，并且在键命名上体现出数据类型，比如使用 bmp:user:online 或 sign:20250601。
场景一：用户签到与连续签到统计
签到是Bitmap最经典的场景。每一天生成一个位图键，键名包含日期，用户ID作为偏移量。用户签到时执行 SETBIT sign:日期 用户ID 1，签到人数统计执行 BITCOUNT sign:日期。由于Bitmap天然去重，同一个用户多次签到不会造成重复计数。这种设计比使用List或Set保存用户ID更加节省内存，尤其当用户规模达到千万甚至亿级时，差距会非常显著。
连续签到统计则可以借助 BITOP AND 实现。比如要找出连续7天都签到的用户，先对最近7天的签到位图执行与运算，结果位图中值为1的位置就是7天全部签到的用户。再对结果执行 BITCOUNT，就能获得连续签到人数。如果需要找连续签到超过3天的用户，可以将最近7天按滑动窗口拆成多组3天组合，分别做与运算后再取并集。这种方式虽然略显繁琐，但相较于逐用户遍历数据库，性能优势明显。
在实际项目中，签到键通常设置过期时间，比如保存最近30天或最近一年的数据。Redis的 EXPIRE 命令可以作用于Bitmap键，因为它本身就是一个字符串键。设置过期时间可以避免历史位图无限累积，但需要注意，一旦键过期，对应的历史签到数据就无法再参与连续统计。更好的做法是定期将旧的签到位图聚合为周统计或月统计结果，再删除原始日数据。
场景二：在线状态与活跃用户去重
在线状态是另一个非常自然的Bitmap应用。以用户ID作为偏移量，1表示在线，0表示离线。用户登录时执行 SETBIT online 用户ID 1，退出时执行 SETBIT online 用户ID 0。统计当前在线人数只需 BITCOUNT online。如果需要按设备类型分别统计在线状态，可以创建 online:ios、online:android 等多个位图，再通过 BITOP OR 计算总在线用户，或通过 BITOP AND 计算同时登录多个设备的用户。
活跃用户去重同样可以用Bitmap。每天用户活跃时执行 SETBIT active:日期 用户ID 1，Bitmap会自动忽略重复用户，因此日活、周活、月活统计都可以通过 BITCOUNT 完成。周活或月活可以先把7天或30天的日活位图做或运算，再统计1的个数。这种方式不需要存储大量用户ID集合，尤其适合用户基数大且活跃比例较高的产品。
但这里需要警惕稀疏场景。假设产品有一亿注册用户，但每日活跃用户只有1万人。Bitmap为覆盖到最大ID用户，仍需要分配约12MB内存；而用Set存储1万个活跃用户ID，即使每个ID按8字节算，也只有约80KB，差距非常悬殊。因此活跃用户去重是否选择Bitmap，关键在于活跃用户分布是否足够稠密。如果活跃用户大量分布在ID空间中，Bitmap更省；如果活跃用户是少量高价值用户，Set通常更划算。
场景三：权限位压缩与特征标记
权限系统通常需要为用户维护多个布尔权限，比如是否允许评论、是否允许上传文件、是否拥有管理权限等。如果每个权限单独存储为一个键，会造成键数量膨胀；如果使用数据库字段，又不利于缓存读取。Bitmap提供了一种更紧凑的方案：将同一个用户的多个权限映射到不同的比特位，一个Bitmap键就可以保存该用户的所有权限开关。读取时使用 BITFIELD 一次读取多个位，既减少请求次数，又便于整体缓存。
例如定义第0位为评论权限，第1位为上传权限，第2位为管理权限，则设置用户1001同时拥有评论和上传权限时，可以执行 BITFIELD user:perm:1001 SET u1 0 1 SET u1 1 1 SET u1 2 0。读取该用户的全部权限时，执行 BITFIELD user:perm:1001 GET u3 0，结果返回一个整数，按位解析即可得到各权限状态。这种做法的优势在于一个键即可完成权限缓存，且占用空间极小。如果权限数量较多，也可以按模块拆分到不同Bitmap键中，避免单个位图偏移量过大。
特征标记是类似的思路。比如用户画像系统中，可以为每个标签维护一个Bitmap，键名为 tag:学生、tag:男性、tag:一线城市，值为符合该标签的用户ID映射。需要同时满足多个标签时，直接对多个标签位图执行 BITOP AND，结果就是同时满足所有标签的用户。需要满足任意一个标签时，使用 BITOP OR。这种标签筛选方式在人群圈选、广告投放和运营活动中有很高价值，因为位运算可以在毫秒级完成复杂人群交集。
场景四：独立访客统计与简单去重
网站希望统计某段时间的独立访客，通常需要记录每个访客的唯一标识。如果访客量很大，使用Set保存所有访客ID可能占用较多内存，而Bitmap可以利用哈希后的整数偏移量来记录访客。将访客ID通过某种整数哈希映射到位图偏移量，执行 SETBIT visitors 偏移量 1，统计 BITCOUNT visitors 即可得到近似独立访客数。
这种方案与HyperLogLog类似，都是概率型去重统计，但Bitmap可以保留具体位的状态，也支持后续做交集、并集分析。缺点是哈希冲突会导致不同访客映射到同一个位，从而低估独立访客数。降低冲突的方式是使用更大的位图，但会相应增加内存。如果对精度要求较高，可以采用多个哈希函数，将访客映射到多个位，但这已经接近布隆过滤器的思路，实现复杂度会上升。
相比之下，如果只是为了快速估算独立访客数，HyperLogLog是更简洁的选择，它在极小内存下即可达到较低误差。Bitmap的优势在于它在获得近似去重结果的同时，还能对一组用户做布尔运算，比如查看同时访问过A页面和B页面的用户群体。因此选择Bitmap还是HyperLogLog，取决于是否需要保留在位图上的位置信息进行二次运算。
选型边界与内存评估
Bitmap的内存占用与最大偏移量直接相关，而不是与设置的1的个数相关。最大偏移量为N，则字符串长度至少为N+1位，对应字节数为 (N+1+7)/8，实际存储还会包含少量Redis字符串头部。如果用户ID不是从0开始连续分布，而是存在极大离线ID，比如少量用户ID超过十亿，Bitmap会被迫扩展到十亿位，造成大量内存浪费。因此在设计偏移量时，应尽量使用连续、自增的用户ID，或者先通过映射函数把稀疏ID压缩到连续区间。
与Set对比，Bitmap更适合稠密二值数据，且不需要执行成员删除以外的集合操作。与HyperLogLog对比，Bitmap更适合需要精确1的个数并且要求可解释、可继续做位运算的场景。对于需要保存用户ID并频繁进行交集、并集、差集、随机弹出等完整集合操作的业务，Set或Sorted Set仍然是更合理的选择。Bitmap并不是通用去重方案，它的优势集中在海量用户、二值状态和批量位运算这三个条件同时成立的场景。
另外，Redis的Bitmap命令对偏移量没有做压缩，也不会自动把连续零位压缩掉。如果业务中存在大量连续零且最大偏移量很大，可以考虑在应用层使用其他压缩位图结构，例如RoaringBitmap，然后将序列化结果存入Redis字符串。这种方式可以兼顾稀疏场景的内存效率，同时保留Redis作为高速缓存的优势。但应用层压缩也带来编解码开销和跨语言一致性成本，需要结合实际场景评估。
总体来看，Redis Bitmap的核心价值在于用极低内存表达海量布尔状态，并通过位运算快速完成交集、并集和连续行为分析。掌握它的命令基础、内存模型和稀疏数据边界，才能在签到、在线状态、权限标记、活跃统计等场景中做出更合适的选型，避免为了追求形式上的低内存而引入不必要的复杂度。
Redis Bitmap位图应用场景修改时间：2026-08-24 15:44:10