Redis 怎么按月保存签到并统计已签天数

可以把签到表压缩成 Redis bitmap：key 使用“用户 + 月份”，当月第 1 天对应 offset 0，第 2 天对应 offset 1，以此类推。签到时执行 SETBIT，查询某天用 GETBIT，统计整月直接用 BITCOUNT。这样一个 31 天月份只需要 31 个有效 bit，重复签到也不会把天数重复计算。

推荐的最小模型是 signin:{user_id}:{yyyyMM}。offset 固定为“业务日期的日号 - 1”，不要直接把日号当 offset；否则每个月都会多出一个无意义的第 0 位。

一、先确定月度 bitmap 的数据模型

假设用户 ID 是 42，业务时区下日期为 2026 年 9 月 5 日，key 可以写成 signin:42:202609，日期偏移是 5 - 1 = 4。同一个用户跨月后切换到 signin:42:202610，统计时不需要清空旧位图，也不会把上月的签到带进本月。

命令行示例：

SETBIT signin:42:202609 4 1
GETBIT signin:42:202609 4
BITCOUNT signin:42:202609

SETBIT 返回被修改前的 bit 值，所以返回 0 通常表示这一天第一次写入，返回 1 表示之前已经签到。它是一个很实用的去重信号，但不要把返回值误当成“当前签到天数”。

二、用 SETBIT 写入，用 GETBIT 查询当天

签到接口只需要把当天 offset 写成 1：

# 9 月 1 日是 offset 0，9 月 30 日是 offset 29
SETBIT signin:42:202609 0 1
SETBIT signin:42:202609 29 1

# 判断 9 月 5 日是否签到
GETBIT signin:42:202609 4

同一天重复执行 SETBIT ... 1 仍然只有一个 1，不会产生重复天数。若业务支持撤销签到或修正误记，可以写入 0，但应把“撤销”作为明确的业务动作，避免客户端重试把已签到状态覆盖掉。

日期计算必须先统一业务时区。不要直接用服务器 UTC 的日号拼 key；在月末跨时区时，可能出现“用户本地已经进入下月，服务端仍写入上月”的错位。key 的月份和 offset 应来自同一个已经转换到业务时区的日期对象。

三、用 BITCOUNT 统计当月已签到天数

整个月的统计最简单：

BITCOUNT signin:42:202609

返回值就是所有值为 1 的 bit 数。Redis 官方文档把 BITCOUNT 标为 O(N)，这里的 N 是被检查的字符串范围；月度签到位图很短时，整 key 统计通常足够。不要为了“优化”而在另一个 key 中维护计数，除非你确实需要跨很大的范围或极高频率读取，否则会引入写入和修正的双写一致性问题。

如果只统计某一段日期，注意范围单位：默认 start end 是字节下标。Redis 7.0 起可以写 BIT，使用 bit 下标：

# 统计 offset 0 到 4，包含首尾，共前 5 天
BITCOUNT signin:42:202609 0 4 BIT

# 默认按字节统计，不能把 0 4 当成前 5 天
BITCOUNT signin:42:202609 0 4

对 31 天月度数据，直接统计整 key 更不容易出错；只有做周统计、阶段统计或更大的 bitmap 时，才需要显式选择 BIT 范围。

四、上线前补齐过期、补签和容量边界

如果只保留最近 13 个月，可以在创建月度 key 后设置过期时间，例如按业务需求给 signin:42:202609 设置 400 天左右的 TTL。TTL 是留存策略，不是签到逻辑的一部分；要先确定补签窗口和对账周期，再决定过期天数。跨月生成新 key 时，不要依赖旧 key 自动“换月”，而应由日期模型明确生成新 key。

高 offset 写入会让 Redis 扩展字符串并分配中间空间，因此不要把用户 ID 当 bit offset，也不要把 Unix 时间戳直接当 offset。签到 bitmap 的 offset 只表示月内第几天，用户隔离放在 key 中。若需要保存每天多次签到、签到时间或设备信息，bitmap 只适合保存“是否发生过”这一位，详细事件应放在其他结构中。

相关问题

重复签到会不会让 BITCOUNT 变大？

不会。同一个 key 和 offset 重复写入 1，仍然只有一个置为 1 的 bit；接口可以根据 SETBIT 返回的旧值决定是否发放首次签到奖励。

为什么月度签到不直接用 Redis Set？

Set 更适合保存具体日期字符串并做成员判断；bitmap 在“每天只有 0/1 状态、需要统计天数”的场景下结构更紧凑。若还要保存补签来源、设备或时间，Set 或 Hash 可能更合适。