当前位置：首页 > 文章列表 > 数据库 > Redis > Redis Bitmap 做连续签到统计：位偏移计算、补签规则与查询性能

Redis Bitmap 做连续签到统计：位偏移计算、补签规则与查询性能

来源：17golang原创 2026-08-25 15:05:24 0浏览收藏

做月度签到时，很多实现会把每天的状态写成一串字符串，再在应用层循环统计连续天数。Redis Bitmap 可以把这件事压缩成按位存储：某天签到就把对应偏移设为 1，查询某个月的签到总数用 BITCOUNT，而连续天数则需要沿着日期倒序逐位判断。这样存储很省，但“签到总数”和“连续签到”不是同一个指标。

要点速览

用日期与月份第一天的差值作为位偏移，不要把自然日直接当偏移。
BITCOUNT 只能回答签到多少天，不能直接回答连续多少天。
补签会改变连续区间，写入后要从目标日期向后复查，而不是只更新一个缓存数字。
按月拆分 Bitmap 更容易控制 key 大小、过期时间和查询范围。

先把“签到一天”压成一个可复查的位

假设用户 42 在 2026 年 8 月 7 日签到，月份 key 使用 checkin:42:2026-08，8 月 1 日对应偏移 0，那么 8 月 7 日的偏移就是 6。命令本身很简单：

SETBIT checkin:42:2026-08 6 1
GETBIT checkin:42:2026-08 6
BITCOUNT checkin:42:2026-08

这里的关键不是记住三条命令，而是固定偏移规则。应用端应该统一用日期差计算 dayIndex，并拒绝跨月日期写入当前 key，否则 9 月 1 日可能被误写到 8 月位图的后面，后续统计会变得很难解释。

Redis Bitmap 按日期计算 dayIndex 后写入签到位并对比统计结果

Bitmap、普通 Set 和字符串数组该怎么选

三种方案都能记录“某天是否签到”，差别在于数据密度和读取方式。Bitmap 最适合日期连续、状态只有 0/1、统计范围明确的场景；Set 更适合日期稀疏或需要直接枚举签到日期；字符串数组便于人工阅读，却通常要付出更大的空间和解析成本。

方案	适合场景	需要留意
Bitmap	按日布尔状态、月度统计	偏移规则必须统一
Set	签到日期稀疏、需要枚举	成员字符串有额外空间
字符串数组	数据量小、调试优先	更新和解析更重

如果业务只问“这个月签到几天”，Bitmap 和 BITCOUNT 很合适；如果要展示最近签到日期，Set 的 SSCAN 或额外的日期索引可能更顺手。不要因为 Bitmap 节省空间，就把所有与签到有关的属性都塞进位图。

连续天数要从今天向前扫描

连续签到的定义通常是从指定日期开始，向前数有多少个连续的 1。下面的伪代码把 Redis 读取和业务判断分开，便于测试：

streak := 0
for dayIndex := todayIndex; dayIndex >= 0; dayIndex-- {
    bit := redis.GetBit(key, dayIndex)
    if bit == 0 {
        break
    }
    streak++
}

今天没有签到时，是否允许从昨天开始计算，是产品规则而不是 Redis 规则。建议把 asOfDate 明确传入查询方法：个人中心显示“当前连续签到”可以用今天；补签页面展示“补签后连续天数”则应以补签日期或业务结算日作为基准。

补签为什么会让缓存的连续天数失真

假设 8 月 4、5、6 日已签到，8 月 3 日漏签，当前连续天数是 3。此时补签 8 月 3 日，位图只增加了一个 1，但连续区间已经从 3 天扩展成 4 天；如果 8 月 2 日也已签到，结果还会继续向前扩展。因此不要只在用户表里把 streak = streak + 1，那会在补签和重复写入时出错。

一种稳妥做法是先用 SETBIT 写入，再从补签日向前和向后分别扫描，重新计算受影响区间。若并发补签要求强一致，可以把“写位 + 重算”放进 Lua 脚本或在应用层按用户串行化；如果允许最终一致，则将重算任务写入队列，页面读取时以位图为准兜底。