做用户画像系统时，最典型的需求是：运营圈选“30岁以下、近7天活跃、偏好数码品类”的用户推送活动。当用户量达到百万甚至上亿级别，如果每个标签都用一张表或者一个Set来存，内存和查询开销会非常惊人。Redis的BitMap正是为这类场景而生的数据结构——它用一个bit位表示一个用户是否具备某个标签，配合位运算可以做到秒级圈选百万人群。
一、BitMap的底层原理与存储估算
Redis中的BitMap并不是一种独立的数据类型，而是基于String类型实现的。String底层是SDS（简单动态字符串），BitMap操作本质上就是对这段字节序列按位读写。当执行SETBIT key offset value时，Redis会计算出offset所在的字节索引和位索引，然后做置位或清零操作，时间复杂度为O(1)。
关键在于内存开销的计算。一个bit表示一个用户，那么1亿用户只需要 100000000 / 8 / 1024 / 1024 ≈ 12MB。对比一下：如果用Redis的Set存储1亿个用户ID，即使每个ID只占8字节，也要接近1GB。这个数量级的差距就是BitMap的核心价值。
不过要注意一个陷阱：BitMap的内存取决于最大offset，而不是用户数量。如果你的用户ID是雪花算法生成的64位长整型，直接用ID做offset会导致offset达到天文数字，Redis会为中间的空洞分配内存，瞬间撑爆实例。所以BitMap方案要求使用连续或紧凑映射后的自增ID。
二、核心命令详解
BitMap相关的命令不多，但每个都很实用。先看基础命令：
# 给用户ID为100的用户打上"男"标签（bit位设置为1） SETBIT tag:male 100 1 # 读取用户100是否有"男"标签，返回0或1 GETBIT tag:male 100 # 统计"男"标签下的用户总数（_population count） BITCOUNT tag:male # 查询第一个值为1的bit位位置 BITPOS tag:male 1
圈选人群时最常用的是BITOP系列命令，它支持AND（交集）、OR（并集）、NOT（非）、XOR（异或）运算。比如圈选“同时是男性且近7天活跃”的用户：
# 计算两个标签的交集，结果写入新的key BITOP AND result tag:male tag:active_7d # 结果集的人数 BITCOUNT result
需要注意，BITOP是同步阻塞操作，如果两个BitMap都很大，执行期间会阻塞Redis主线程。生产环境建议在从库上执行，或者控制单次运算的位图规模。另外BITCOUNT支持指定字节范围参数，可以配合游标做分批统计。
三、Spring Boot实战：打标签与人群圈选
下面给出一段可直接落地的Java代码，展示如何在业务系统中完成打标签、判断标签和人群交集计算。Spring Data Redis提供了stringRedisTemplate.opsForValue().setBit()方法：
@Service
public class UserTagService {
@Autowired
private StringRedisTemplate redisTemplate;
// 给用户打标签，userId必须是紧凑自增ID
public void addTag(String tagName, long userId) {
String key = "tag:" + tagName;
redisTemplate.opsForValue().setBit(key, userId, true);
}
// 移除标签
public void removeTag(String tagName, long userId) {
redisTemplate.opsForValue().setBit("tag:" + tagName, userId, false);
}
// 判断用户是否拥有某标签
public boolean hasTag(String tagName, long userId) {
Boolean bit = redisTemplate.opsForValue().getBit("tag:" + tagName, userId);
return Boolean.TRUE.equals(bit);
}
// 圈选：多个标签取交集，返回人数
public long countIntersection(String resultKey, String... tagNames) {
byte[][] keys = Arrays.stream(tagNames)
.map(t -> ("tag:" + t).getBytes())
.toArray(byte[][]::new);
redisTemplate.execute((RedisConnection conn) -> {
conn.bitOp(RedisStringCommands.BitOperation.AND,
resultKey.getBytes(), keys);
return null;
});
Long count = redisTemplate.execute((RedisConnection conn) ->
conn.bitCount(resultKey.getBytes()));
return count == null ? 0 : count;
}
}
实际项目中，打标签的动作通常由离线任务（如Spark、Flink计算完用户属性后）批量写入，线上服务只负责查询和圈选。批量写入时建议用pipeline把上千次SETBIT打包发送，能把耗时降低一个数量级。
拿到交集结果后，如果还要导出具体用户ID列表，可以遍历BitMap逐位检测，但更高效的做法是用BITPOS循环定位下一个为1的位，跳过大片空区，性能远好于逐位扫描。
四、稀疏ID与超大规模场景的进阶方案
前面反复强调BitMap依赖紧凑ID。如果业务ID无法改造，常见的做法是维护一张“业务ID到自增序号”的映射表，可以放在Redis的Hash或者MySQL中，打标签时先做一次转换。这层转换带来的开销通常可以接受，因为映射关系可以本地缓存。
对于数值标签（比如年龄段、消费等级），可以巧妙利用bit宽度：用BITFIELD命令在一个key中为每个用户分配固定宽度的字段。例如每个用户占4个bit，就能表达0到15的16个分档值：
# 从offset 0开始，为用户10写入u4类型的值5（表示年龄段分档） BITFIELD tag:age_group SET u4 #10*4 5 # 读取用户10的年龄段分档 BITFIELD tag:age_group GET u4 #10*4
当用户群体极度稀疏（只有10%用户拥有某标签），BitMap的12MB里大部分都是0，此时可以考虑RoaringBitMap这类压缩位图。Java生态中有开源库，它对稠密区域直接存bit、稀疏区域存数组，内存能再压缩一个数量级，代价是运算稍慢且通常需要放在应用层内存而非Redis中。
总结一下方案边界：标签值是布尔型、用户ID可映射为连续整数、需要频繁做交并集运算，这三点都满足时BitMap是性价比最高的选择；如果标签值是连续数值就用BITFIELD；如果数据极度稀疏或无法改造ID，再考虑RoaringBitMap或回到Set方案。技术选型没有银弹，理解数据结构和业务形态的匹配度，才是做对决策的关键。
Redis BitMap用户画像标签存储修改时间：2026-09-09 13:53:05