在 Redis 中，位图的每个分片确实对应一个独立的键值对（Key-Value Pair）。
下面这个表格清晰地展示了分片位图的构成逻辑：
| 概念层级 | 对应关系 | 示例 |
|---|---|---|
| 整个位图 | 一个完整的业务数据集 | 记录所有用户的签到状态 |
| 一个分片 | 一个独立的 Redis 键 (Key) | sign:202501:0, sign:202501:1 |
| 分片内的一个位 (Bit) | 键所对应的字符串值中的某一个二进制位 | 键 sign:202501:0 的第 10 位为 1，表示用户 ID 为 10 的用户已签到 |
深入理解分片与键的关系
这种设计的核心在于 Redis 数据模型和位图的实现原理：
- Redis 的键值对模型 ：Redis 是一个键值存储系统，每个数据都通过一个唯一的键来访问。值可以是多种数据类型，位图（Bitmap）在技术上就是字符串（String）类型 ，只不过 Redis 提供了直接操作字符串中特定位的命令（如
SETBIT,GETBIT）。 - 分片的本质 ：当数据量巨大（例如用户ID达到亿级）时，一个庞大的位图（即一个很长的字符串）会导致操作性能下降（因为
BITCOUNT等操作的时间复杂度是 O(N)），并且可能触及 Redis 字符串 512MB 的最大容量限制（约 42.9 亿个位）。为了解决这个问题，我们将一个逻辑上的大位图水平切分成多个较小的位图，每个小位图就是一个分片，并赋予其独立的键名。 - 键的设计 ：分片键的名称通常包含业务标识和分片标识。例如，
active:20250111:0这个键可以表示为 2025 年 1 月 11 日的活跃用户数据，第 0 号分片。通过这样的命名，我们在逻辑上仍然将它们视为一个整体，但在物理存储和操作上则是分散的。
如何操作分片位图？
当需要读取或设置某个用户的状态时，需要两步计算来确定操作哪个键以及键内的哪个位：
- 计算分片键 (Key) ：
shard_id = user_id / 分片大小 - 计算键内偏移量 (Offset) ：
offset = user_id % 分片大小
假设分片大小为 10,000，要设置用户 ID 为 123456 的签到状态：
- 分片键 ：
123456 / 10000 = 12，所以键名为sign:202501:12 - 偏移量 ：
123456 % 10000 = 3456 - 执行命令 ：
SETBIT sign:202501:12 3456 1
分片策略参考
选择合适的分片大小是关键，需要在性能和内存管理上取得平衡：
| 分片策略 | 分片大小（示例） | 优点 | 缺点 |
|---|---|---|---|
| 细粒度分片 | 较小（如 10,000 用户/片） | 单个键体积小，操作速度快，数据分布均匀 | 键数量增多，管理稍复杂 |
| 粗粒度分片 | 较大（如 1,000,000 用户/片） | 键数量少，管理简单 | 可能仍有性能瓶颈，内存分配可能不灵活 |
一个常见的建议是将单个位图的大小控制在 10MB 以内（约 800 万位），以获得最佳性能。