Redis SETBIT 怎么设计签到位图：偏移量、BITCOUNT 统计与跨月清理

月度签到统计最容易出现一种不显眼的错：页面显示 31 次，但用户明明只在当月签到了 30 天。排查后通常不是 Redis 丢了数据，而是日期没有先换成从 0 开始的偏移，或者跨月时还在复用上一张位图。用 Redis 的 SETBIT 保存每天是否签到，再用 BITCOUNT 统计 1 的数量，规则很小，但边界必须写死。

一个自然月对应一个 key，日期 d 映射到 d-1 位；重复签到只覆盖原位，月末切换 key 后再回收旧 key。

为什么签到总数会多一天

Redis 位图的偏移从 0 开始，而业务日期从 1 开始。若把 1 月 1 日写到 offset=1，整个月的位会整体右移一格；更麻烦的是，某些代码会把 31 号写到 31，导致 Redis 多占一个位置，统计虽然看似还能用，却掩盖了日期映射错误。

这篇只保留一个明确模型：每个用户每个月一张位图，key 形如 user:42:signin:2026-08。当天日期先计算成 day-1，然后把这个偏移交给 SETBIT。

把日期映射成位偏移

下面的 Go 函数只负责生成月度 key 和偏移，不把时区转换藏进 Redis 命令里。生产代码应先把请求时间转换成业务时区，再取日期；否则 UTC 零点附近可能把签到写进前一天。

func signinKey(t time.Time, userID int64, loc *time.Location) (string, int) {
    local := t.In(loc)
    monthKey := local.Format("2006-01")
    return fmt.Sprintf("user:%d:signin:%s", userID, monthKey), local.Day() - 1
}

// 2026-08-01 -> user:42:signin:2026-08, offset=0
key, offset := signinKey(now, 42, time.FixedZone("CST", 8*60*60))
oldBit, err := rdb.SetBit(ctx, key, int64(offset), 1).Result()
if err != nil {
    return err
}
firstSignin := oldBit == 0

这里有三个可以直接核对的节点：SETBIT 写入位图，day-1 把 1 号落到第 0 位，BITCOUNT 后续负责汇总这些已置 1 的位。SETBIT 返回的是旧位值，所以重复请求不会把签到次数再次加一。

用 BITCOUNT 得到稳定的月度总数

查询月度总数时直接对同一个 key 执行 BITCOUNT 即可。它统计的是位图中值为 1 的位，不需要业务侧保存一份容易被重复请求污染的计数器。

func signinCount(ctx context.Context, rdb *redis.Client, key string) (int64, error) {
    return rdb.BitCount(ctx, key, nil).Result()
}

count, err := signinCount(ctx, rdb, "user:42:signin:2026-08")
if err != nil {
    return err
}
fmt.Println("August signin count:", count)

如果用户在 8 月 1 日重复点击三次，第一次 SETBIT 返回旧值 0，后两次返回旧值 1；最终 BITCOUNT 仍然只得到 1。这个返回值也适合用来决定是否写入“首次签到”积分，但积分发放最好和业务流水放在同一个可靠的幂等流程里，不要把位图当成完整账本。

跨月时切换 key，再处理旧月份

9 月 1 日到来时，新的 key 应是 user:42:signin:2026-09，而不是继续写 8 月的位图。应用层按请求日期生成 key，自然完成切换；旧 key 是否删除，则取决于是否还要展示历史月度统计。

currentKey := "user:42:signin:2026-09"
previousKey := "user:42:signin:2026-08"

current, _ := rdb.BitCount(ctx, currentKey, nil).Result()
previous, _ := rdb.BitCount(ctx, previousKey, nil).Result()
fmt.Println(current, previous)

// 只保留最近月份时，在确认报表已落库后回收旧 key
if err := rdb.Del(ctx, previousKey).Err(); err != nil {
    return err
}

这条路径的顺序是 month key 先切到当月，再由 BITCOUNT 分别读取当前和历史月，最后才由 DEL 回收旧数据。不要在报表读取前删除上一月 key，也不要用一个没有月份后缀的固定 key，否则月底会把两个自然月混成一张图。

上线前检查四个边界

• 1 号：确认写入偏移是 0，且月度总数从 1 开始。
• 重复请求：检查 SETBIT 的旧值，不能每次都新增签到记录。
• 月末：验证 28、29、30、31 日不会超出当月日期范围。
• 跨月回收：先确认报表或归档完成，再执行 DEL。

如果业务需要补签，建议让补签接口也走同一个日期映射函数；不要在另一个入口里直接传“第几位”。同一用户、同一月份的位图只表达是否发生过签到，无法单独表达签到时间、来源和补签原因。

相关问题

SETBIT 返回 0 就代表 Redis 里没有这个 key 吗？

不代表。它表示指定偏移之前是 0；key 可能已经存在，只是这一位尚未置 1。

为什么不用 INCR 直接记录签到天数？

INCR 很难独立防住同一天的重复请求，而位图天然把“日期是否已经签到”压在一个固定位置上，BITCOUNT 还能从原始状态重新计算总数。

月度位图需要设置过期时间吗？

如果只保留近几个月，可以在归档确认后设置 TTL 或执行 DEL；如果页面支持历史查询，应先把统计结果写入长期存储，再回收 Redis key。

小结

Redis SETBIT 方案的关键不在命令数量，而在边界一致：业务日期先换成 day-1，用户和月份进入 key，BITCOUNT 负责可重算统计，跨月时切换 month key 后再决定是否 DEL。把这四点写成测试用例，签到总数多一天的问题通常就能在上线前被挡住。