Redis SETBIT 怎样设置跨字节位图偏移

Redis 的 SETBIT 并不是按“第几个字节”写入，而是按从 0 开始的 bit offset 设置或清除某一位。要跨过字节边界，只需要继续递增 offset：0 到 7 落在第一个字节，8 到 15 落在下一个字节。也就是说，offset 7 和 offset 8 是相邻字节的最后一位和第一位。

官方地址：https://redis.io/docs/latest/commands/setbit/

SETBIT 的 offset 怎样跨过字节边界

Redis 位图实际存储在 String 中，但命令接口把它看成连续的 bit 序列。第一个字节对应 offset 0 到 7，第二个字节对应 offset 8 到 15。业务代码不需要自己拆 byte，也不应该把“跨字节”理解成要换一条命令。

因此，如果把用户编号直接当作 offset，用户 8 会自然落到第二个字节的第一个 bit。若业务编号从 1 开始，通常要使用 offset = id - 1；若编号可能跳跃，则要先明确是否接受稀疏扩容。

用 SETBIT 写入跨字节状态

下面用一个登录状态位图演示：把编号 0、7、8、9 置为 1。这个例子特意包含 7 到 8 的边界，便于观察写入逻辑不需要特殊分支。

# 清理旧数据，避免上一次实验留下置位
redis-cli DEL user:logged-in

# offset 0、7、8、9 分别写入 1，其中 7 和 8 跨越字节边界
redis-cli SETBIT user:logged-in 0 1
redis-cli SETBIT user:logged-in 7 1
redis-cli SETBIT user:logged-in 8 1
redis-cli SETBIT user:logged-in 9 1

# 把 offset 9 清零，SETBIT 的 value 也可以是 0
redis-cli SETBIT user:logged-in 9 0

每次 SETBIT 返回的是该位置写入前的旧值，而不是写入后的新值。例如第一次设置一个原本为 0 的位置，返回通常是 0；再次把同一位置设置为 1，返回的旧值可能就是 1。如果业务要知道“这次是否首次置位”，这个返回值就有用。

写入后怎样用 GETBIT 和 BITCOUNT 核对

GETBIT 适合检查一个明确的 offset，BITCOUNT 适合统计整个位图中值为 1 的 bit 数量。两者回答的问题不同：前者是单点状态，后者是整体计数。

# 检查字节边界两侧的单点状态，offset 7 与 8 都应为 1
redis-cli GETBIT user:logged-in 7
redis-cli GETBIT user:logged-in 8

# 统计整个位图中当前被置为 1 的 bit 数量
redis-cli BITCOUNT user:logged-in

# 查看 Redis 为当前字符串分配了多少字节，辅助发现稀疏大 offset
redis-cli STRLEN user:logged-in

本例最后把 offset 9 清零，所以 BITCOUNT 只统计仍为 1 的位置。STRLEN 返回的是底层字符串长度，不是置位数量；一个很长但只有少数 bit 为 1 的字符串，正是稀疏 offset 需要关注的情况。

在 Go 代码里封装业务编号映射

在 Go 应用中，建议把“业务编号转换成 offset”单独封装，并在进入 Redis 前限制编号范围。go-redis 的 SetBit 会返回旧 bit 值，适合把首次置位作为一次状态变化处理。

package main

import (
    "context"
    "fmt"

    "github.com/redis/go-redis/v9"
)

// markUser 把从 1 开始的业务编号转换为从 0 开始的 bit offset。
func markUser(ctx context.Context, client *redis.Client, key string, userID int64) (bool, error) {
    if userID 

这里业务编号 9 被映射为 offset 8，正好落在第二个字节的第一位。若业务编号可能超过预期范围，可以在 userID 检查后再增加最大值限制，避免意外创建过大的 String。

扩容、并发和大 offset 的边界

当 key 不存在时，SETBIT 会创建 String；当 offset 超出当前长度时，Redis 会把字符串扩展到能够容纳该 bit，中间新增的 bit 为 0。连续编号通常会得到紧凑的存储，但直接写入一个极大的 offset 可能触发较大的内存分配和阻塞风险。

offset 的上限是小于 2^32，这对应位图最多约 512 MB 的 String 空间。这个上限不是业务容量建议：在实际系统中还要根据内存预算、编号密度和访问频率设置更小的应用层上限。

• 编号规则：固定“业务编号 1 对应 offset 0”还是“编号直接作为 offset”，并写进接口说明。
• 稀疏编号：如果编号可能从很大的值开始，先评估 String 扩容，而不是只看置位数量。
• 并发写入：SETBIT 是单条命令，多个客户端写不同 offset 时不需要客户端锁；复杂的多步判断仍需重新设计原子边界。
• 结果核对：用 GETBIT 看单点，用 BITCOUNT 看数量，用 STRLEN 观察底层字符串长度，三者不要混为一谈。

常见问题

offset 7 和 offset 8 为什么不是同一个字节？

每 8 个 bit 组成一个字节，第一个字节覆盖 0～7，第二个字节从 8 开始。SETBIT 只处理连续 offset，不需要应用层手动进位。

SETBIT 返回 1，是不是表示这次写入成功？

它表示写入前该位置的旧值是 1。命令成功与否由错误返回判断；旧值用于识别状态是否发生变化。

为什么 BITCOUNT 数量很小，但 STRLEN 很大？

通常是因为某个较大的 offset 让 String 扩展了很多中间字节，但只有少数位置被置为 1。应限制 offset 或改用更紧凑的编号映射。

业务编号从 1 开始时应该怎么办？

常见做法是统一使用 offset = userID - 1，这样编号 1 落在 offset 0；关键是读写两端必须采用同一规则。

SETBIT 的跨字节写入本身很简单，真正需要固定的是编号映射和容量边界：先决定业务编号如何转换，再用 GETBIT、BITCOUNT、STRLEN 分别核对单点、数量和底层长度。这样既能正确使用 offset 8 之后的位，也能尽早发现稀疏大 offset 带来的扩容问题。