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

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

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

假设用户 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 月位图的后面，后续统计会变得很难解释。

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

三种方案都能记录“某天是否签到”，差别在于数据密度和读取方式。Bitmap 最适合日期连续、状态只有 0/1、统计范围明确的场景；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 脚本或在应用层按用户串行化；如果允许最终一致，则将重算任务写入队列，页面读取时以位图为准兜底。

查询性能和 key 设计的几个边界

• 按月建 key：月度位图最多约 31 位，key 边界直观，归档也简单。
• 避免对超大范围频繁逐位 GETBIT：连续统计应限制最大回溯天数，或维护经过验证的周期汇总。
• 写入要幂等：同一天重复 SETBIT ... 1 不会重复计数，但积分奖励不能直接跟着每次请求发放。
• 检查空 key 和越界日期：没有签到记录时，BITCOUNT 返回 0，应用层不要把它误判成一次异常。

在压测时分别记录 BITCOUNT、单日 GETBIT 和连续扫描的耗时。前三者的复杂度和访问次数不同，混在一个平均值里很容易掩盖最慢的那条路径。

常见问题

BITCOUNT 能直接得到连续签到天数吗？

不能。它统计指定 key 或字节范围内的 1 的总数，两个不相邻的签到日也会被一起计算。连续天数需要从基准日期逐位判断，直到遇到第一个 0。

为什么不把全年签到放进一个 Bitmap？

全年位图本身不大，但按月拆分更容易处理自然月统计、冷热数据和过期策略。只有当业务经常跨年查询，并且已经定义好日期偏移规则时，全年 key 才更合适。

补签后应该立刻更新连续天数缓存吗？

可以更新，但不能只做加一。应根据补签前后的位图重新扫描受影响区间，并让重复补签保持幂等；如果采用异步重算，读取端仍应能从 Bitmap 得到正确兜底值。

落地时记住这条判断线

Bitmap 解决的是“每天有没有签到”的紧凑存储问题，连续签到、补签奖励和跨月展示则属于业务计算。把日期偏移、统计口径和重算触发条件写进接口契约，再用几组跨月、断签、补签和重复请求用例验收，后续换 key 结构时才不会只看空间占用而漏掉语义错误。