Redis用SETBIT记录签到状态方法

Redis通过SETBIT指令将用户每日签到状态压缩至1bit，使1万用户一年的签到数据仅占用13KB，相比String存储“1”/“0”节省超90%内存；但需科学设计——以年为单位分key（如user:sign:1001:2024）、用距基准日的整数偏移量作offset、结合BITPOS定位最近断签日与BITCOUNT统计连续天数，同时规避客户端整数溢出、跨年数据膨胀及字节/位范围混淆等陷阱，方能在极小内存开销下实现高效、准确、可维护的签到系统。

SETBIT 存连续签到为什么比用 String 或 Hash 节省 90%+ 内存

因为 Bitmap 把每个用户每天的签到状态压缩成 1 个 bit，1 万个用户一年签到数据不到 13KB；而用 String 存 “1”/“0” 字符串，光一年就要近 3.6MB，差两个数量级。

实际用法是：以用户 ID 为 key，日期偏移量为 offset，调用 SETBIT 标记当天是否签到：

SETBIT user:sign:1001 0 1   # 第 0 天（比如 2024-01-01）签到
SETBIT user:sign:1001 1 1   # 第 1 天（2024-01-02）签到
SETBIT user:sign:1001 5 0   # 第 5 天未签到

• offset 从 0 开始，建议统一用「距基准日的天数」计算，比如基准日定为 2024-01-01，那么 2024-01-10 对应 offset = 9
• 不要用日期字符串（如 "20240110"）当 offset —— SETBIT 只接受整数，非数字会报错 (error) ERR bit is not an integer or out of range
• Redis 默认对不存在的 key 自动创建，但位图长度按需扩展；高位未设置的 bit 默认为 0，GETBIT 查询时无需预初始化整段

查连续签到天数得用 BITPOS + BITCOUNT 组合，不能只靠 GETBIT

GETBIT 只能查单日状态，要算「当前最长连续签到」必须定位到最近一个 0 的位置，再减去上一个 0 的位置 —— 这事得靠 BITPOS 扫描。

典型做法是：从今天往前找第一个未签到日（即值为 0 的 bit），再用 BITCOUNT 统计这段区间内 1 的个数：

BITPOS user:sign:1001 0 -1    # 从末尾向前找第一个 0，返回 offset
BITCOUNT user:sign:1001 0 9   # 统计 offset 0 到 9（共 10 天）里有几个 1

• BITPOS key 0 -1 中的 -1 表示从右往左扫描，适合查「最近断签日」；若用正数（如 100），则只在前 100 位里找
• BITCOUNT 的 range 参数是字节范围，不是 bit 偏移！如果想统计第 5～14 天（共 10 天），offset 是 5～14，对应字节范围是 5/8 到 14/8 向上取整，容易算错 —— 更稳妥是用 Lua 脚本封装逻辑
• 注意：BITPOS 找不到目标值时返回 -1，别直接拿它做减法，否则连续天数变成负数

跨年或长期运行时，key 过期和分片必须手动处理

Bitmap 不支持按 bit 设置过期，整个 key 只能共用一个 TTL。签到数据若跨多年，不清理旧 key 会导致内存持续增长，且 BITCOUNT 会把历史无效位全算进去。

• 方案一：按年分 key，比如 user:sign:1001:2024、user:sign:1001:2025，每年初用 EXPIRE 设 366 天过期
• 方案二：用 BITFIELD 配合 INCRBY 记录最后签到日，再结合定时任务清理早于某日期的 key —— 但 BITFIELD 不支持位图区间清零，删 key 是最干脆的方式
• 切记：不要依赖 Redis 自动淘汰策略来“保活”签到 key，LRU/LFU 对 bitmap 无效，冷 key 仍占内存

PHP/Python 客户端调用 SETBIT 时，offset 超过 2³²−1 会静默失败

Redis 协议限制 SETBIT 的 offset 最大为 2^32 - 1（约 42.9 亿），换算成天数就是 1170 万年 —— 理论够用，但客户端语言可能提前截断。

• PHP 的 redis->setBit() 在 32 位系统或某些旧扩展里，传入大整数会被转成 float，导致精度丢失，SETBIT key 2147483648 1 可能变成 SETBIT key 2147483647 1
• Python 的 redis-py 通常没问题，但若用 int(time.time()) 直接当 offset（误以为是时间戳），会远超范围 —— offset 必须是小整数（建议控制在 0~1095 内，即三年）
• 调试技巧：用 DEBUG OBJECT key 查看底层编码是否为 raw（正常）或 embstr（小 key 优化），异常时可能是 offset 写崩了结构

offset 算错、key 没分年、客户端整数溢出 —— 这三处出问题，表现都是查不到签到记录或连续天数突然归零，但错误日志里几乎不报，得靠 BITCOUNT 和 STRLEN 对比验证位图实际长度。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis用SETBIT记录签到状态方法》文章吧，也可关注golang学习网公众号了解相关技术文章。