一文搞懂 Redis Bitmap

Redis，作为一款高性能的键值存储系统，以其丰富的数据结构和闪电般的存取速度在各类应用中占据着核心地位。除了我们熟知的 String、List、Set、Sorted Set、Hash 等结构，Redis 还提供了一些更为特殊和高效的数据结构，Bitmap（位图）便是其中之一。

Bitmap 并不是 Redis 的一种独立数据类型，它实际上是构建在 Redis 的 String 数据类型之上的。它将 String 视为一个由二进制位组成的序列，通过对序列中的特定位进行设置或获取，来实现对大量布尔（真/假）状态的高效存储和操作。

听起来可能有点抽象，但它在处理海量用户状态、行为统计等场景时，能展现出惊人的空间效率和计算性能。本文将深入浅出地带你彻底理解 Redis Bitmap：它的本质是什么？为什么它如此高效？如何使用它？有哪些常见的应用场景？以及它的优缺点和注意事项。

一、 Bitmap 的本质：一个高效的布尔数组

想象一下，你需要记录系统中 1000 万个用户的某个二值状态，比如：

用户今天是否登录了？
用户是否是高级会员？
用户是否对某个功能开启了 A/B Test？

对于每一个用户，这个状态只有“是”或“否”两种可能。如果使用传统的 Redis 数据结构，比如 Set，你需要存储 1000 万个表示“是”的用户 ID。如果用户 ID 是数字，例如 user:active:today 这个 Set 里存储了所有今天活跃的用户的 ID。存储 1000 万个整数会占用相当可观的内存。

而 Bitmap 提供了一种极致的空间压缩方式来存储这种二值信息。它的核心思想是：用一个比特位（bit）来表示一个独立元素的布尔状态。

一个比特位只有 0 和 1 两种状态，这天然对应了“否”和“是”。如果我们有 1000 万个用户，我们可以创建一个足够长的比特序列，序列的第 N 个比特就用来表示用户 ID 为 N 的状态。如果用户 ID 为 N 的比特是 1，表示状态为真；如果是 0，则表示状态为假。

这就像是有一个巨大的开关面板，面板上有 1000 万个开关，每个开关对应一个用户。用户上线了，就把对应的开关打开 (1)；没上线或者下线了，就把开关关掉 (0)。

为什么说它构建在 Redis String 之上？

Redis 的 String 数据类型最大可以存储 512MB 的数据。String 本质上是一个字节数组（byte array）。一个字节（byte）等于 8 个比特位（bit）。Redis Bitmap 就是利用 String 的这个特性，将 String 内部的字节数组视为一个超长的比特序列。

当你操作 Bitmap 时，比如设置第 100 个比特位为 1，Redis 实际上会计算出这个比特位位于 String 的哪个字节的哪个位置：
* 第 100 个比特位是 String 的第 100 / 8 = 12 个字节中的第 100 % 8 = 4 个比特（注意：通常按大端序或小端序来计算具体是第几位，Redis 采用小端序，即一个字节的最低有效位是第 0 位，最高有效位是第 7 位）。所以，第 100 个比特位是位于 String 的第 12 个字节的第 4 个比特位（从0开始计数）。
* Redis 会读取 String 的第 12 个字节，将它的第 4 个比特位设置为 1，然后将修改后的字节写回 String。

如果设置的比特位偏移量（offset）超出了当前 String 的长度，Redis 会自动扩展 String，并在新的空间用零进行填充，直到能够容纳指定的偏移量。

空间效率对比：Set vs. Bitmap

假设我们有 1000 万个用户，用户 ID 是从 0 到 9999999 的整数。

使用 Set 存储今天登录的用户 ID： 如果有 100 万用户登录，Set 需要存储 100 万个整数。每个整数在 Redis 中通常需要占用 8 字节（如果使用压缩列表或跳跃表等优化可能不同，但大致是这个量级，加上Set本身的开销）。保守估计，100万 * 8 字节 ≈ 8 MB。如果用户 ID 是长字符串，开销会更大。而且 Set 的开销不仅仅是存储元素本身，还有维护哈希表或跳跃表的额外开销。
使用 Bitmap 存储今天登录的用户状态： 我们需要一个 Bitmap，它的长度至少能容纳到用户 ID 9999999。这意味着我们需要 1000 万个比特位。1000 万比特位 = 10,000,000 / 8 字节 = 1,250,000 字节 = 1.25 MB。
- 即使只有 1 个用户登录（比如用户 ID 9999999），Bitmap 也需要扩展到包含这个 offset，即约 1.25 MB。但如果有 100 万用户登录，只要他们的 ID 在 0-9999999 范围内，占用的空间仍然是约 1.25 MB。
- 相比之下，Set 随着活跃用户数量增加，内存占用线性增长。Bitmap 的内存占用主要取决于最高设置的那个比特位的偏移量，而不是设置了多少个比特位。

可见，在用户 ID 密集分布且状态为二值的情况下，Bitmap 在空间效率上有巨大优势。它用最紧凑的方式存储了“用户 ID -> 布尔状态”的映射。

二、 Bitmap 的核心命令详解

Redis 提供了一系列命令来操作 Bitmap：

SETBIT key offset value
GETBIT key offset
BITCOUNT key [start] [end]
BITOP operation destkey key [key...]
BITPOS key bit [start] [end]

下面我们逐一详细介绍这些命令。

1. `SETBIT key offset value`

功能： 设置指定 key 的 Bitmap 中，给定偏移量 offset 的比特位的值为 value。value 只能是 0 或 1。
参数：
- key: Bitmap 的键名。
- offset: 比特位的偏移量，从 0 开始计数。
- value: 要设置的值，必须是 0 或 1。
返回值： 返回该偏移量原来存储的比特位的值 (0 或 1)。
示例：

“`bash

将键名为 ‘user_activity:20231027’ 的 Bitmap 中，

偏移量为 100 的比特位设置为 1 (表示用户ID 100 今天活跃)

SETBIT user_activity:20231027 100 1

返回: 0 (假设原来是0)

将偏移量为 200 的比特位设置为 1

SETBIT user_activity:20231027 200 1

返回: 0

将偏移量为 100 的比特位重新设置为 0 (表示用户ID 100 今天不活跃了或标记为不活跃)

SETBIT user_activity:20231027 100 0

返回: 1

设置一个非常大的偏移量，Redis 会自动扩展 String，用0填充中间部分

SETBIT user_activity:20231027 10000000 1

返回: 0

“`

注意事项： 如果 offset 很大，Redis 会根据需要扩展 String。String 会用字节 0x00（即所有位都是 0）来填充直到 offset 所在的字节。这意味着 Bitmap 的内存占用是由最高设置的 offset 决定的，而不是由设置了多少个 1 决定的。例如，只设置 SETBIT mybitmap 1000000000 1 会立即占用约 120MB 内存 (1000000000 / 8 字节)。

2. `GETBIT key offset`

功能： 获取指定 key 的 Bitmap 中，给定偏移量 offset 的比特位的值。
参数：
- key: Bitmap 的键名。
- offset: 比特位的偏移量，从 0 开始计数。
返回值： 指定偏移量上的比特位的值 (0 或 1)。如果 key 不存在或者 offset 超出 String 的范围，返回 0。
示例：

“`bash

获取键名为 ‘user_activity:20231027’ 的 Bitmap 中，偏移量为 100 的比特位的值

GETBIT user_activity:20231027 100

返回: 0 (根据上面的 SETBIT 操作)

获取偏移量为 200 的比特位的值

GETBIT user_activity:20231027 200

返回: 1

获取一个未设置过的或超出范围的偏移量的值

GETBIT user_activity:20231027 500

返回: 0

“`

3. `BITCOUNT key [start] [end]`

功能： 计算指定 key 的 Bitmap 中，值为 1 的比特位的数量。可以指定一个字节范围 [start, end] 进行计算。
参数：
- key: Bitmap 的键名。
- start (可选): 统计的起始字节偏移量（从 0 开始）。
- end (可选): 统计的结束字节偏移量。start 和 end 都是基于字节的偏移量，而不是比特位的偏移量。Redis 会处理负数索引，类似于 Python 列表索引（-1 表示最后一个字节，-2 表示倒数第二个字节等）。
返回值： 值为 1 的比特位的数量。如果 key 不存在，返回 0。
示例：

“`bash

计算整个 Bitmap 中值为 1 的比特位的数量 (活跃用户总数)

BITCOUNT user_activity:20231027

返回: 1 (因为只设置了 offset 200 和 10000000 为 1，offset 100 被改回了 0)

计算前 10 个字节范围内的比特位数量 (对应用户ID 0 到 79)

BITCOUNT user_activity:20231027 0 9

返回: 0 (假设这个范围内没有设置 1)

计算倒数 10 个字节范围内的比特位数量

BITCOUNT user_activity:20231027 -10 -1

返回: 1 (假设 offset 10000000 在最后一个字节范围内)

“`

注意事项： BITCOUNT 的时间复杂度是 O(N)，其中 N 是统计的字节范围的大小。如果不对范围进行限制，N 是整个 String 的长度。对于大型 Bitmap，全范围 BITCOUNT 可能会比较耗时，但在实际应用中，Redis 对这个操作进行了高度优化，通常速度很快。

4. `BITOP operation destkey key [key...]`

功能： 对一个或多个 Bitmap 执行位操作（AND, OR, XOR, NOT），并将结果存储到 destkey。
参数：
- operation: 位操作类型，可以是 AND、OR、XOR、NOT。
- destkey: 存储结果的键名。
- key [key...]: 要进行操作的源 Bitmap 键名，NOT 操作只能接受一个源 key。
返回值： 结果 Bitmap 的大小（以字节为单位）。
示例：

假设我们有以下 Bitmap：
* user_activity:20231027: 用户 ID 100, 200 活跃
* user_activity:20231028: 用户 ID 200, 300 活跃

“`bash

计算用户ID 100, 200 今天 (20231027) 是否活跃

SETBIT user_activity:20231027 100 1
SETBIT user_activity:20231027 200 1

计算用户ID 200, 300 昨天 (20231028) 是否活跃 (注：这里假设昨天，实际应用中 key 名称会反映日期)

SETBIT user_activity:20231028 200 1
SETBIT user_activity:20231028 300 1

——– BITOP 操作 ——–

BITOP AND: 找出今天和昨天都活跃的用户 (用户ID 200)

BITOP AND active_both_days user_activity:20231027 user_activity:20231028

返回: 结果 Bitmap 的字节大小

active_both_days 这个 Bitmap 中只有 offset 200 的位是 1

BITOP OR: 找出今天或昨天任一天活跃过的用户 (用户ID 100, 200, 300)

BITOP OR active_either_day user_activity:20231027 user_activity:20231028

返回: 结果 Bitmap 的字节大小

active_either_day 这个 Bitmap 中 offset 100, 200, 300 的位都是 1

BITOP XOR: 找出今天和昨天只有一天活跃过的用户 (用户ID 100, 300)

BITOP XOR active_xor_days user_activity:20231027 user_activity:20231028

返回: 结果 Bitmap 的字节大小

active_xor_days 这个 Bitmap 中 offset 100, 300 的位都是 1

BITOP NOT: 找出今天不活跃的用户。

注意：NOT 操作是对 Bitmap 中的每个比特位取反。如果 Bitmap 范围很大，对整个 Bitmap 取反可能不是你想要的。

比如 user_activity:20231027 只有 offset 100, 200 是 1，其他所有位都是 0。对它进行 NOT 操作会把 100, 200 变成 0，把其他所有 0 变成 1。

通常 NOT 操作需要结合其他操作或明确的范围来使用，或者应用于已知范围的场景。

例如，如果知道总用户 ID 范围是 0-1000，可以先创建一个所有位都是 1 的 Bitmap 作为“全集”，再用 BITOP AND 和 NOT 来找到不在 today_active 中的用户。

这里简单示例对已知范围的 NOT：

假设我们只关心用户ID 0-400范围

BITOP NOT inactive_today_first_400 user_activity:20231027 0 49 # (NOT不支持范围参数，这个示例不准确)

正确的做法是 BITOP NOT 操作没有范围参数，它操作的是整个字符串。如果想在特定范围内计算不在 today_active 中的用户，

更常见的方法是获取一个“所有用户”的 Bitmap（如果存在）或者通过其他方式处理。

BITOP NOT inactive_today user_activity:20231027

结果 inactive_today 中 offset 100, 200 是 0，其他位是 1。

这可能包含大量超出实际用户 ID 范围的 1，需要小心使用。

“`

注意事项： BITOP 是一个非常有用的命令，尤其适合计算用户群体的交集、并集、差集等。参与操作的 Bitmap 长度不同时，较短的 Bitmap 会被视为在末尾填充了 0。BITOP NOT 操作会对整个 String 进行位反转，这可能会导致结果 Bitmap 比源 Bitmap 大得多，并且包含许多在源 Bitmap 中是 0 的位变为 1，需要特别注意其影响。

5. `BITPOS key bit [start] [end]`

功能： 查找指定 key 的 Bitmap 中，第一个值为 bit (0 或 1) 的比特位的偏移量。可以指定一个字节范围 [start, end] 进行搜索。
参数：
- key: Bitmap 的键名。
- bit: 要查找的比特位的值 (0 或 1)。
- start (可选): 搜索的起始字节偏移量（从 0 开始）。
- end (可选): 搜索的结束字节偏移量。同样是基于字节的偏移量，支持负数索引。
返回值： 第一个匹配的比特位的偏移量。如果在指定范围内没有找到，或者 key 不存在，则返回 -1。
示例：

“`bash

假设 user_activity:20231027 中 offset 100, 200, 10000000 是 1，其他位是 0

SETBIT user_activity:20231027 100 1
SETBIT user_activity:20231027 200 1
SETBIT user_activity:20231027 10000000 1

查找第一个值为 1 的比特位

BITPOS user_activity:20231027 1

返回: 100

查找第一个值为 0 的比特位 (从 offset 0 开始，第一个位就是 0)

BITPOS user_activity:20231027 0

返回: 0

在指定字节范围内查找第一个值为 1 的比特位

假设 offset 100 在某个字节范围内，offset 200 在另一个字节范围内

例如，查找从第 10 个字节开始到第 20 个字节范围内的第一个 1

BITPOS user_activity:20231027 1 10 20

返回: 如果 offset 100 在这个范围内，则返回 100。否则返回 -1。

“`

注意事项： BITPOS 对于查找第一个满足条件的元素非常有用。它的时间复杂度也是 O(N)，其中 N 是搜索的字节范围大小。

三、 Bitmap 的内部实现细节

理解 Bitmap 的内部实现有助于更好地使用它：

底层是 String： 正如前述，Bitmap 就是 Redis 的 String 类型。它是一个字节数组。
偏移量与字节/位映射：
- 比特位偏移量 offset 对应 String 的第 offset / 8 个字节。
- 在该字节内，它对应第 offset % 8 个比特位。
- 例如，offset 0 是第 0 字节的第 0 位，offset 8 是第 1 字节的第 0 位，offset 9 是第 1 字节的第 1 位。
按需扩展和填充： 当使用 SETBIT 设置一个超出当前 String 长度的偏移量时，Redis 会自动扩展 String。扩展的方式是填充 0x00 字节，直到能够包含目标偏移量。例如，一个空的 Bitmap (长度为 0)，如果你执行 SETBIT mybitmap 15 1，Redis 会将 String 扩展到 2 个字节 (15 / 8 = 1 余 7，需要用到第 1 个字节，总共需要 0 和 1 两个字节)，并设置第 1 个字节的第 7 个比特位为 1。在此之前，第 0 个字节和第 1 个字节（除了第 7 位）都会是 0。
内存占用： Bitmap 的内存占用与最高设置的比特位偏移量成正比（具体地说，是 (highest_offset / 8) + 1 字节），而不是与设置了多少个 1 成正比。这一点非常重要。如果你的用户 ID 分布非常稀疏（比如只有用户 1 和用户 10 亿是活跃的），使用 Bitmap 可能会消耗大量内存来存储中间的零。Bitmap 最适合 ID 密集分布的场景。
最大偏移量： 由于底层是 String，Bitmap 的最大偏移量受到 Redis String 最大长度的限制，即 512MB。512MB 共有 512 * 1024 * 1024 * 8 ≈ 4.3 * 10^9 个比特位。因此，一个 Bitmap 最多可以支持约 43 亿个独立元素的二值状态。

四、 Bitmap 的常见应用场景

基于其高效的空间利用率和位操作能力，Bitmap 在以下场景中大放异彩：

用户活跃度统计 (UV – Unique Visitors)
- 需求： 统计网站或应用的每日、每周、每月活跃用户数量。
- 方案： 使用一个 Bitmap 键，以日期作为 key 的一部分（例如 user_active:YYYYMMDD）。用户 ID 作为 offset。当用户登录或访问时，执行 SETBIT user_active:YYYYMMDD userId 1。
- 统计日活跃用户 (DAU)： BITCOUNT user_active:YYYYMMDD 即可快速获得当天的活跃用户数。
- 统计周活跃用户 (WAU)： 使用 BITOP OR 将本周每天的 Bitmap 合并到一个新的 Bitmap (例如 user_active:weekly:YYYYWW)：BITOP OR user_active:weekly:YYYYWW user_active:YYYYMMDD1 user_active:YYYYMMDD2 ...。然后 BITCOUNT user_active:weekly:YYYYWW 即可。
- 统计月活跃用户 (MAU)： 同理，使用 BITOP OR 合并当月每天的 Bitmap。
- 统计留存用户： 使用 BITOP AND 将今天和昨天/上周/上月的活跃用户 Bitmap 进行 AND 操作，结果 Bitmap 中的 1 就是同时活跃的用户（留存用户）。例如，统计日留存：BITOP AND retained:today_yesterday user_active:today user_active:yesterday，再对 retained:today_yesterday 进行 BITCOUNT。
用户在线状态追踪
- 需求： 快速判断大量用户是否在线。
- 方案： 使用一个 Bitmap 键（例如 user_online_status），用户 ID 作为 offset。用户上线时 SETBIT user_online_status userId 1，用户下线时 SETBIT user_online_status userId 0。
- 判断用户是否在线： GETBIT user_online_status userId。
- 统计在线人数： BITCOUNT user_online_status。
用户标签系统
- 需求： 记录用户是否拥有某个特定标签（如：高级会员、邮箱已验证、App 已安装等）。
- 方案： 为每个标签创建一个 Bitmap 键（例如 user_tag:premium、user_tag:email_verified）。用户 ID 作为 offset。用户拥有标签则 SETBIT user_tag:tagName userId 1，否则为 0。
- 判断用户是否有某个标签： GETBIT user_tag:tagName userId。
- 找出同时拥有多个标签的用户： 使用 BITOP AND user_tag:premium user_tag:email_verified user_tag:app_installed 将多个标签的 Bitmap 进行 AND 操作，结果 Bitmap 中的 1 就是同时拥有这些标签的用户 ID。
功能权限或 A/B Test 用户分流
- 需求： 控制某个功能对部分用户可见或将用户分配到不同的 A/B Test 组。
- 方案： 为每个功能或 A/B Test 组创建一个 Bitmap（例如 feature_flags:new_profile_page 或 ab_test:checkout_v2:groupA）。用户 ID 作为 offset。将需要开启功能或分到该组的用户 ID 对应的比特位设置为 1。
- 检查用户是否有权限/在哪个组： GETBIT feature_flags:new_profile_page userId。
商品或内容的点赞/收藏统计
- 需求： 记录哪些用户点赞/收藏了某个商品或内容。
- 方案： 使用商品/内容 ID 作为 key 的一部分，用户 ID 作为 offset（例如 item_likes:itemId）。用户点赞时 SETBIT item_likes:itemId userId 1。
- 统计点赞数： BITCOUNT item_likes:itemId。
- 判断用户是否点赞： GETBIT item_likes:itemId userId。

这些场景都涉及大量元素的二值状态，Bitmap 通过将这些状态压缩到比特级别，极大地节省了内存，并通过原生的位操作命令提供了高效的统计和计算能力。

五、 Bitmap 的优缺点

优点：

极致的空间效率： 对于密集分布的二值状态数据，Bitmap 是最省内存的数据结构之一。每个状态只需要一个比特位。
快速的位操作： BITCOUNT 和 BITOP 命令在处理大量数据时性能优异，能够进行高效的交集、并集、差集计算，这在统计和分析用户行为时非常有用。
O(1) 的比特位存取： SETBIT 和 GETBIT 操作在给定偏移量时，其时间复杂度可以视为 O(1)（严格来说是 O(N/8)，N是字符串长度，但对于单个位操作而言，涉及到的字节很少，可以认为接近常数时间）。
简洁的数据模型： 直接将整数 ID 映射到布尔状态，模型简单直观。

缺点：

内存占用取决于最高偏移量： 如果用户 ID 非常稀疏，或者最高的用户 ID 非常大但活跃用户很少，Bitmap 可能会因为填充大量的 0 字节而占用大量内存。例如，如果有用户 ID 1 和用户 ID 10 亿，Bitmap 至少需要约 120MB 内存，即使中间的 ID 都没有被设置。
不适合非整数 ID： Bitmap 要求使用非负整数作为偏移量，无法直接使用字符串 ID。如果用户 ID 是字符串，需要进行额外的映射处理。
不适合稀疏数据（大偏移量）： 如果需要存储的状态对应的 ID 分布非常不均匀，且存在极大的 ID，Bitmap 的空间效率优势会丧失，甚至不如 Set。
获取所有设置的比特位比较麻烦： Redis 没有直接的命令可以迭代 Bitmap 中所有值为 1 的比特位偏移量。如果需要获取所有活跃用户的 ID 列表，通常需要结合其他方法，例如扫描所有可能的偏移量（效率极低）或者在设置比特位的同时将用户 ID 存储到 Set 或 Sorted Set 中。
最大偏移量限制： 虽然 43 亿个比特位已经非常大，但对于某些极大规模的应用可能仍然需要考虑分片或其他策略。

六、 Bitmap 与 Set 的对比

在很多需要记录“谁做了什么”的场景下，Bitmap 和 Set 都是可选方案，但它们各有侧重：

特性	Redis Bitmap	Redis Set
底层实现	基于 String (字节数组)	基于哈希表 (用于快速查找)
存储内容	隐式存储整数 ID（通过偏移量），状态是布尔值	存储任意唯一的字符串或整数
空间效率	对密集整数 ID 的二值状态非常高效，每个状态 1 bit	存储的元素数量越多，内存占用越高，每个元素开销较大
内存取决于	最高设置的比特位偏移量	存储的元素数量和元素大小
添加/检查	`SETBIT`/`GETBIT` (O(1) by offset)	`SADD`/`SISMEMBER` (O(1))
计数	`BITCOUNT` (O(N) by byte range)	`SCARD` (O(1))
集合运算	`BITOP` (AND, OR, XOR, NOT) (O(N) by byte range)	`SINTER`, `SUNION`, `SDIFF` (O(N), N 是集合大小)
迭代元素	不直接支持，需要外部逻辑或辅助数据结构	`SMEMBERS`, `SSCAN` (支持迭代)
适合场景	海量二值状态，ID 密集且为整数，需要频繁进行群体状态的位运算	存储任意唯一元素，需要快速成员检查、去重、集合运算

总结来说：

如果你处理的是大量的整数 ID，并且只需要记录每个 ID 对应的二值状态（是/否），同时非常关注内存效率和群体状态的位运算（交集、并集、差集），那么 Bitmap 是更优的选择。它用空间换取了位操作的便利和极致的内存压缩。
如果你处理的是非整数 ID，或者需要存储的元素不止是二值状态，或者 ID 分布非常稀疏，或者你需要方便地获取所有成员列表，那么 Set 或其他数据结构可能更合适。

七、使用 Bitmap 的一些注意事项和进阶技巧

合理规划 Key 和 Offset：
- Key 的设计应体现 Bitmap 的含义和维度（例如，按日期分键 user_active:YYYYMMDD，按标签分键 user_tag:premium）。
- Offset 通常对应你的业务实体 ID（如用户 ID、商品 ID）。确保这些 ID 是非负整数，并且尽量是连续或分布在可接受的范围内，以避免因大偏移量造成的内存浪费。如果 ID 是 UUID 或其他字符串，需要一个额外的映射层将其转换为整数偏移量。
处理大偏移量或稀疏数据： 如果你的 ID 非常大或分布非常稀疏，考虑以下策略：
- ID 映射： 在应用层维护一个“内部 ID”到“实际 ID”的映射，让内部 ID 从 0 开始连续分配。Bitmap 使用内部 ID 作为 offset。
- 数据分片： 如果最高 ID 超过 43 亿，或者单个 Bitmap 过大，可以按 ID 范围将数据分散到多个 Redis 键甚至多个 Redis 实例中。
- 考虑其他数据结构： 如果稀疏问题严重到 Bitmap 失去空间优势，重新评估是否应该使用 Set 或其他结构。
范围操作 (BITCOUNT, BITPOS 的 start/end)： 记住 start 和 end 参数是基于字节的偏移量。这在你想统计或查找某个特定用户 ID 范围（例如用户 ID 1000 到 2000）内的状态时，需要将用户 ID 偏移量转换为对应的字节偏移量范围。start_byte = start_user_id / 8, end_byte = end_user_id / 8。需要注意的是，这只是粗略映射，一个字节可能包含多个用户 ID 的状态，范围计算时需要仔细考虑边界。通常，范围参数用于在大的 Bitmap 中只处理一部分数据以提高效率。
Bitmap 的持久化和同步： Bitmap 作为 String 类型存储在 Redis 中，遵循 Redis 的持久化 (RDB/AOF) 和主从同步机制。
原子性： Redis 的命令是原子性的，SETBIT, BITCOUNT, BITOP 等命令都是原子操作。
数据过期： Bitmap 键也支持设置过期时间 (EXPIRE 命令)，这对于按时间维度存储的 Bitmap (如每日活跃用户) 非常有用，可以自动清理旧数据。

八、总结

Redis Bitmap 是一种强大且高度优化的数据结构，特别适用于处理海量元素的二值状态。它通过将每个状态存储为单个比特位，提供了无与伦比的空间效率，并利用位运算实现了对群体状态的快速统计和分析。

理解 Bitmap 的本质是基于 Redis String 的一个比特序列，其内存占用取决于最高设置的偏移量，是掌握其用法的关键。通过 SETBIT 设置状态，GETBIT 获取状态，BITCOUNT 统计数量，BITOP 进行集合运算，以及 BITPOS 查找特定状态的第一个位置，我们可以解决许多实际应用中的问题，尤其是在用户行为分析、标签管理和权限控制等领域。

然而，Bitmap 并非万能。对于非整数 ID、数据分布稀疏或需要获取所有成员列表的场景，可能需要结合其他数据结构或采取额外的策略。

熟练掌握 Redis Bitmap，将为你处理大规模二值数据提供一种高效且节省成本的利器。希望通过本文的详细介绍，你已经彻底“搞懂”了 Redis Bitmap，并能在未来的开发中灵活运用它。

一文搞懂 Redis Bitmap

一、 Bitmap 的本质：一个高效的布尔数组

二、 Bitmap 的核心命令详解

1. SETBIT key offset value

将键名为 ‘user_activity:20231027’ 的 Bitmap 中，

偏移量为 100 的比特位设置为 1 (表示用户ID 100 今天活跃)

返回: 0 (假设原来是0)

将偏移量为 200 的比特位设置为 1

返回: 0

将偏移量为 100 的比特位重新设置为 0 (表示用户ID 100 今天不活跃了或标记为不活跃)

返回: 1

设置一个非常大的偏移量，Redis 会自动扩展 String，用0填充中间部分

返回: 0

2. GETBIT key offset

获取键名为 ‘user_activity:20231027’ 的 Bitmap 中，偏移量为 100 的比特位的值

返回: 0 (根据上面的 SETBIT 操作)

获取偏移量为 200 的比特位的值

返回: 1

获取一个未设置过的或超出范围的偏移量的值

返回: 0

3. BITCOUNT key [start] [end]

计算整个 Bitmap 中值为 1 的比特位的数量 (活跃用户总数)

返回: 1 (因为只设置了 offset 200 和 10000000 为 1，offset 100 被改回了 0)

计算前 10 个字节范围内的比特位数量 (对应用户ID 0 到 79)

返回: 0 (假设这个范围内没有设置 1)

计算倒数 10 个字节范围内的比特位数量

返回: 1 (假设 offset 10000000 在最后一个字节范围内)

4. BITOP operation destkey key [key...]

计算用户ID 100, 200 今天 (20231027) 是否活跃

计算用户ID 200, 300 昨天 (20231028) 是否活跃 (注：这里假设昨天，实际应用中 key 名称会反映日期)

——– BITOP 操作 ——–

BITOP AND: 找出今天和昨天都活跃的用户 (用户ID 200)

返回: 结果 Bitmap 的字节大小

active_both_days 这个 Bitmap 中只有 offset 200 的位是 1

BITOP OR: 找出今天或昨天任一天活跃过的用户 (用户ID 100, 200, 300)

返回: 结果 Bitmap 的字节大小

active_either_day 这个 Bitmap 中 offset 100, 200, 300 的位都是 1

BITOP XOR: 找出今天和昨天只有一天活跃过的用户 (用户ID 100, 300)

返回: 结果 Bitmap 的字节大小

active_xor_days 这个 Bitmap 中 offset 100, 300 的位都是 1

BITOP NOT: 找出今天不活跃的用户。

注意：NOT 操作是对 Bitmap 中的每个比特位取反。如果 Bitmap 范围很大，对整个 Bitmap 取反可能不是你想要的。

比如 user_activity:20231027 只有 offset 100, 200 是 1，其他所有位都是 0。对它进行 NOT 操作会把 100, 200 变成 0，把其他所有 0 变成 1。

通常 NOT 操作需要结合其他操作或明确的范围来使用，或者应用于已知范围的场景。

例如，如果知道总用户 ID 范围是 0-1000，可以先创建一个所有位都是 1 的 Bitmap 作为“全集”，再用 BITOP AND 和 NOT 来找到不在 today_active 中的用户。

这里简单示例对已知范围的 NOT：

假设我们只关心用户ID 0-400范围

BITOP NOT inactive_today_first_400 user_activity:20231027 0 49 # (NOT不支持范围参数，这个示例不准确)

正确的做法是 BITOP NOT 操作没有范围参数，它操作的是整个字符串。如果想在特定范围内计算不在 today_active 中的用户，

更常见的方法是获取一个“所有用户”的 Bitmap（如果存在）或者通过其他方式处理。

BITOP NOT inactive_today user_activity:20231027

结果 inactive_today 中 offset 100, 200 是 0，其他位是 1。

这可能包含大量超出实际用户 ID 范围的 1，需要小心使用。

5. BITPOS key bit [start] [end]

假设 user_activity:20231027 中 offset 100, 200, 10000000 是 1，其他位是 0

查找第一个值为 1 的比特位

返回: 100

查找第一个值为 0 的比特位 (从 offset 0 开始，第一个位就是 0)

返回: 0

在指定字节范围内查找第一个值为 1 的比特位

假设 offset 100 在某个字节范围内，offset 200 在另一个字节范围内

例如，查找从第 10 个字节开始到第 20 个字节范围内的第一个 1

返回: 如果 offset 100 在这个范围内，则返回 100。否则返回 -1。

三、 Bitmap 的内部实现细节

四、 Bitmap 的常见应用场景

五、 Bitmap 的优缺点

六、 Bitmap 与 Set 的对比

七、 使用 Bitmap 的一些注意事项和进阶技巧

八、 总结

发表评论 取消回复

1. `SETBIT key offset value`

2. `GETBIT key offset`

3. `BITCOUNT key [start] [end]`

4. `BITOP operation destkey key [key...]`

5. `BITPOS key bit [start] [end]`

七、使用 Bitmap 的一些注意事项和进阶技巧

八、总结

发表评论取消回复