2.1 SETBIT 的时间复杂度陷阱#

Redis 官方文档对 SETBIT 的复杂度定义：

这是问题的直接原因：Redis Bitmap 底层是一个原始 bit 数组，首次 SETBIT 时必须把 0 到 offset 之间的所有字节都分配出来并清零。

2.2 内存分配量化#

offset 经哈希取模后均匀分布在 0 ~ 42.9 亿之间，期望值约 21.4 亿。

2.3 为什么后续操作快？#

Key 一旦存在，内存已分配完毕，后续 SETBIT/GETBIT 都是 O(1)，所以第二次及之后操作正常。这也解释了为什么问题容易被忽视——开发/测试时第二次操作就正常了，只有”首次”才会暴露。

2.4 能否缩小 Offset 范围？#

直觉方案：把取模上限从 2^32 缩小到 2^20（约 100 万），首次写入只需分配 128 KB。

问题：哈希碰撞导致数据错误。

不同 userId 可能映射到同一个 offset：

碰撞概率（生日悖论公式）：

结论：缩小 Offset 到不卡的范围，碰撞率对热门内容不可接受。性能和正确性无法兼得。

3.1 雪花 ID 的结构决定了它不适合做 Bitmap offset#

雪花 ID（64 bit）的结构：

1
┌──────────────────────────────────────────────────────────────────┐
2
│ 1 bit  │       41 bit        │  10 bit  │       12 bit          │
3
│ 符号位  │     时间戳(ms)       │  机器ID   │      序列号           │
4
│  0     │  1746000000000+...  │  0~1023  │      0~4095           │
5
└──────────────────────────────────────────────────────────────────┘

一个典型的雪花 ID：2051776854918803458（约 2 × 10^18）

核心矛盾：Bitmap offset 的有效范围是 0 ~ 2^32 - 1（约 42.9 亿），而雪花 ID 的值域是 0 ~ 2^63 - 1（约 9.2 × 10^18），差了 20 亿倍。

3.2 哈希取模是”治标不治本”的妥协#

1
userId → hash64() 散列 → % (2^32 - 1) → offset

这带来了两个问题：

问题 1：取模后的值仍然很大

hash64() 输出均匀分布在 Long.MIN_VALUE ~ Long.MAX_VALUE，取模后均匀分布在 0 ~ 2^32-1。期望值约 21.4 亿，首次写入仍需分配 ~256 MB。

问题 2：取模引入碰撞

取模是压缩映射，必然存在多对一关系。两个不同的 userId 可能映射到同一个 offset，导致数据错误。

3.3 雪花 ID 的”时间递增”特性也无法利用#

有人可能想：雪花 ID 是递增的，早期用户的 ID 较小，offset 不会太大？

不对——因为 hash64() 打散了原始 ID 的递增特性：

1
userId=1         → hash64 → 0x7A3B2C1D4E5F6A7B → % 2^32 → 1,823,456,789
2
userId=2         → hash64 → 0x1234567890ABCDEF → % 2^32 → 3,456,789,012
3
userId=100       → hash64 → 0xFEDCBA0987654321 → % 2^32 → 987,654,321

即使 userId 很小，hash 后的 offset 仍然可能很大。递增特性被哈希完全破坏了。

3.4 如果不用哈希，直接用雪花 ID 做 offset 呢？#

更糟——雪花 ID 本身就是 19 位数字（~2^61），远超 Bitmap offset 上限 2^32，直接用会报错：

1
ERR bit offset is not an integer or out of range

3.5 从 ID 生成策略角度的替代方案#

如果一定要用 Bitmap，需要让 ID 变小：

结论：在雪花 ID 体系下，没有好的办法让 ID 变小到适合 Bitmap。换数据结构比换 ID 方案成本更低。

3.6 雪花 ID 角度的本质#

1
雪花 ID 的本质：全局唯一、趋势递增、64 bit
2
Bitmap offset 的本质：紧凑整数、0~2^32、bit 位映射
3

4
两者设计目标根本不同：
5
  雪花 ID → 保证唯一性 → 值域必须大
6
  Bitmap offset → 紧凑映射 → 值域必须小
7

8
强行用哈希取模桥接，既丢失了唯一性（碰撞），又没解决紧凑性（offset 仍大）。

4.1 Redis 单线程阻塞：一个慢操作拖垮整个节点#

Redis 是单线程模型（命令串行执行），一个 SETBIT key 2147483648 1 需要分配 256 MB 并清零，在此期间该 Redis 节点无法响应任何其他请求。

1
时间线：
2
t0  客户端A: SETBIT collect:bit:1:xxx 2147483648 1  ← 开始分配 256MB
3
t1  客户端B: GET user:info:123                       ← 排队等待...
4
t2  客户端C: INCR like:count:1:456                   ← 排队等待...
5
t3  客户端D: SADD follow:user:789:1 999              ← 排队等待...
6
t4  SETBIT 完成（耗时 2~5 秒）                        ← 客户端 B/C/D 全部超时
7
t5  客户端 B/C/D 的命令才开始执行

影响范围：不仅是收藏操作本身慢，同一 Redis 节点上的所有业务（登录、查询、计数）都会被阻塞。

4.2 Redis Cluster 数据倾斜#

Redis Cluster 按 Key 的 hash slot 分配到不同节点。Bitmap 方案下：

1
collect:bit:1:10086  → slot A → 节点 1
2
collect:bit:1:10087  → slot B → 节点 2
3
collect:bit:2:10086  → slot C → 节点 3

如果某篇爆款文章首次被大量用户收藏，所有 SETBIT 操作都打到同一个 Key，即同一个节点。该节点瞬间承受：

• 内存分配压力（单次 256 MB）
• CPU 压力（memset 清零）
• 网络压力（响应延迟导致连接堆积）

而其他节点完全空闲——典型的数据倾斜。

4.3 KEYS 命令的集群隐患#

同步任务中通常使用 KEYS collect:bit:* 扫描所有 Bitmap Key：

1
Collection<String> keys = redisTemplate.keys("collect:bit:*");

在 Redis Cluster 中：

• KEYS 命令只扫描当前节点，需要用 SCAN 逐节点遍历
• KEYS 是 O(N) 操作，会阻塞当前节点
• 大量 Bitmap Key 时，同步任务本身也可能成为性能瓶颈

4.4 Bitmap 大 Key 的运维风险#

4.5 分布式角度的结论#

5.1 原理#

RoaringBitmap 是压缩位图，将 32 位整数空间分成 65536 个桶，每桶按数据稀疏程度选择容器：

设置 offset=20 亿时，只需在对应桶里加一个元素（Array Container，2 bytes），不会分配 250 MB。

5.2 三种使用方式对比#

1
RB.SETBIT key 2000000000 1    -- O(1)，不预分配
2
RB.GETBIT key 2000000000      -- O(1)

1
byte[] data = redisTemplate.opsForValue().get(key);
2
RoaringBitmap bitmap = data != null
3
    ? RoaringBitmap.deserialize(data) : new RoaringBitmap();
4
bitmap.add(userId);
5
redisTemplate.opsForValue().set(key, bitmap.serialize());

5.3 RoaringBitmap 结论#

除非能装 RedisBloom 模块，否则 RoaringBitmap 客户端方案会丢失原子性，得不偿失。

6.1 Key 设计#

1
# 1. 操作总数（内容维度）—— String
2
like:count:{targetType}:{targetId}    →  INCR / DECR
3

4
# 2. 用户操作集合（用户维度）—— Set
5
like:user:{userId}:{targetType}       →  SADD / SREM / SISMEMBER

6.2 为什么用用户维度而不是内容维度的 Set？#

用户维度的 Set 天然上限合理，加 TTL（如 7 天）冷数据自动淘汰。

6.3 操作流程#

1
// 点赞
2
Boolean added = redisTemplate.opsForSet().isMember(
3
    "like:user:" + userId + ":1", String.valueOf(targetId));
4
if (Boolean.TRUE.equals(added)) {
5
    throw new BusinessException("已点赞");
6
}
7
redisTemplate.opsForSet().add("like:user:" + userId + ":1",
8
    String.valueOf(targetId));
9
redisTemplate.opsForValue().increment("like:count:1:" + targetId);
10
// 异步写 MySQL
11

12
// 取消点赞
13
redisTemplate.opsForSet().remove("like:user:" + userId + ":1",
14
    String.valueOf(targetId));
15
redisTemplate.opsForValue().decrement("like:count:1:" + targetId);
16
// 异步删 MySQL
17

18
// 判断是否已点赞
19
Boolean isLiked = redisTemplate.opsForSet().isMember(
20
    "like:user:" + userId + ":1", String.valueOf(targetId));

6.4 缓存冷启动（Redis 无数据时）#

1
Boolean isLiked = redisTemplate.opsForSet().isMember(key, String.valueOf(targetId));
2
if (isLiked == null) {
3
    // key 不存在，从 MySQL 回捞
4
    RLock lock = redisson.getLock("lock:like:load:" + userId);
5
    lock.lock();
6
    try {
7
        List<Long> likedIds = likeMapper.selectByUserId(userId, targetType);
8
        if (CollUtil.isNotEmpty(likedIds)) {
9
            redisTemplate.opsForSet().add(key,
10
                likedIds.stream().map(String::valueOf).toArray());
11
        }
12
        redisTemplate.expire(key, 7, TimeUnit.DAYS);
13
    } finally {
14
        lock.unlock();
15
    }
16
}

6.5 方案对比#

6.6 前端注意事项：雪花 ID 精度丢失#

雪花 ID 约 19 位数字，超过 JS Number.MAX_SAFE_INTEGER（2^53 ≈ 16 位），JSON 序列化会丢精度：

1
// 前端接收后
2
1234567890123456789  →  1234567890123456800  // 末尾精度丢失

解决方案：Jackson 序列化时将 Long 转 String。

1
// 方式一：字段级注解
2
@JsonSerialize(using = ToStringSerializer.class)
3
private Long targetId;
4

5
// 方式二：全局配置 ObjectMapper
6
@Bean
7
public ObjectMapper objectMapper() {
8
    ObjectMapper mapper = new ObjectMapper();
9
    SimpleModule module = new SimpleModule();
10
    module.addSerializer(Long.class, ToStringSerializer.instance);
11
    module.addSerializer(Long.TYPE, ToStringSerializer.instance);
12
    mapper.registerModule(module);
13
    return mapper;
14
}

三维问题全景#

1
┌─────────────────────────────────────────────────────────────────────┐
2
│                        问题全景图                                     │
3
├──────────────┬──────────────────────────────────────────────────────┤
4
│              │  首次写入 O(offset) 分配数百 MB 内存                    │
5
│  Bitmap 本身  │  缩小 Offset → 碰撞率不可接受                         │
6
│              │  性能与正确性无法兼得                                    │
7
├──────────────┼──────────────────────────────────────────────────────┤
8
│              │  64 bit vs 32 bit offset，差 20 亿倍                   │
9
│  雪花 ID     │  哈希取模：既丢唯一性（碰撞），又没解决紧凑性（offset 仍大） │
10
│              │  递增特性被哈希破坏，无法利用                              │
11
│              │  换 ID 方案成本远高于换数据结构                           │
12
├──────────────┼──────────────────────────────────────────────────────┤
13
│              │  单线程阻塞：一个慢操作拖垮整个节点                       │
14
│  分布式      │  数据倾斜：爆款内容所有操作打同一个节点                    │
15
│              │  大 Key 运维：DEL/RDB/AOF/主从同步全受影响               │
16
│              │  KEYS 扫描：Cluster 不友好 + O(N) 阻塞                 │
17
└──────────────┴──────────────────────────────────────────────────────┘

问题-方案对照表#

最终选型#

String（计数）+ Set（用户维度，判断是否已操作）+ 异步写库。

不用 Bitmap（雪花 ID 太大），不用内容维度 Set（爆款 Key 太大），不用 RoaringBitmap（原子性难保证）。

什么时候 Bitmap 仍然适用？#

Bitmap 并非一无是处，以下场景仍然是最优选择：

核心判断标准：offset 是否为紧凑小整数（万级以内）。如果是雪花 ID，直接放弃 Bitmap。