1. 原理概览
1.1 位图在签到场景中的作用
在签到场景中，位图是以日期为分片的、按用户ID偏移保存签到状态的高效结构。每一个比特位对应一个用户的每日签到状态，设置为1表示已签到，0表示未签到；通过O(1)时间决定某个用户是否已完成当天签到。这种设计的核心优势在于极致的空间利用率与吞吐性能，特别适用于分布式环境下的去重与幂等处理。
将签到状态分成每日一个位图，能让系统以简单的键前缀和位操作实现跨节点的并发写入与查询。对于海量用户的签到记录，每一天的位图只记录需要的位信息，从而避免了传统日志或关系型表的高成本存储与查询开销。
1.2 Redis 位图的基本结构
Redis 位图是通过SETBIT、GETBIT、BITOP等命令实现对位的读写与聚合，键名通常以日期作为分片前缀，如 sign:YYYYMMDD，位偏移量由用户ID决定。该结构的内在特性是：写入一个位的成本是常数时间，读取同样是常数时间，且对未初始化的位会隐式扩展位图容量。
在设计中，常见的做法是：将每日签到状态放在单独的位图中，并通过位操作将多日数据聚合，方便月度或季度分析。本文将围绕这一思路，介绍实现与优化要点。
# 将用户 12345 在日期 20240604 的签到状态设为 1
SETBIT sign:20240604 12345 1# 查询用户 12345 在日期 20240604 是否已签到
GETBIT sign:20240604 12345
2. 实现设计
2.1 数据模型与存储
核心设计点是日期分片的位图+按用户ID偏移的位操作。键名命名为 sign:YYYYMMDD，位偏移量为用户唯一标识（通常是数字ID）。这种设计的好处是：新增签到只需要一个 SETBIT 操作，读取一个 GETBIT 操作即可完成幂等性判断，并且对单日的查询和统计开销极低。
为了实现快速的跨日聚合，通常会在需要时使用 BITOP 将多日位图聚合到一个目标位图中，以便统计连续日期区间的活跃签到情况。该方法在统计、筛选和分析阶段提供了极大便利，同时保持了高吞吐和低延迟。
2.2 签到写入与去重策略
写入时，通过 SETBIT 将当天用户的签到位设为 1，若重复签到，位并不会产生额外开销，因为再次设置同一位不会改变结果。这样的幂等性特性对于分布式环境中的重复提交极为友好。
为了快速判断是否需要写入或触发后续流程，可以在应用层先执行 GETBIT，若返回 0 再执行 SETBIT；当然，直接执行 SETBIT 也是可接受的，因为 Redis 的位图写入成本极低，且能在单次原子操作中完成任务。
# 先判断再写入（可选）
GETBIT sign:20240604 12345
# 如果返回 0，则执行写入
SETBIT sign:20240604 12345 1
# 直接写入（幂等性来自于写入同一位置不会改变逻辑结果）
SETBIT sign:20240604 12345 1
3. 性能优化
3.1 空间与时间复杂度分析
单日位图的内存开销与覆盖的最大用户ID相关。若仅记录活跃用户数较小的场景，位图往往能以极低的内存成本实现海量币位的签到状态，但若用户ID分布很稀疏，仍会按实际最大位偏移扩展位图。理论上，数据读写的时间复杂度为 O(1)，受限于网络和 Redis 实例本身的吞吐。
以常见的规模估算，若日活用户数量达到 1,000,000，理论上仅需要约 125 KB 的位图内存来表示这些位之间的状态；若要覆盖全量用户ID（如 10^9 量级），内存需求将显著增加。因此在设计阶段需要权衡业务峰值、ID分布及服务器内存资源，必要时采取分区、分层缓存等策略。
# 获取单日签到位图的总签到人数近似（统计全部 1 的位数）
BITCOUNT sign:20240604
3.2 位图聚合与BITOP的应用
为了跨日统计和分析，可以使用 BITOP 将多日位图聚合成一个目标位图。例如，将若干天的签到位图按位进行 OR 操作，得到某个时间区间的合并结果，便于快速判定是否在该区间内有签到活动。
在聚合后，可以结合 BITCOUNT 统计聚合位图中为 1 的位数量，反映活跃签到用户数；也可以将聚合结果作为后续数据分析的输入。
# 将 20240601~20240603 三天的签到位图按位或合并到一个目标位图
BITOP OR sign:20240601_03 sign:20240601 sign:20240602 sign:20240603# 统计合并后的活跃签到人数
BITCOUNT sign:20240601_03
4. 可靠性与监控
4.1 容错与持久化策略
在高可用场景中，尽量采用 主从复制、持久化策略（AOF/RDB）与滚动快照组合，以降低单点故障带来的风险。签到位图的变更非常频繁，因此 配置 AOF 的同步策略与合适的快照频率尤为关键，以保障数据在重启后尽量保留最近的签到状态。
另外，对跨数据中心的部署，使用只读副本处理签到查询，将写入集中在主节点，可以在保持一致性的同时提升查询吞吐量和系统稳定性。
# 示例：开启 AOF 并设置持久化策略
# 在 redis.conf 中：
# appendonly yes
# appendfsync everysec
4.2 监控维度与告警
有效的监控要覆盖内存使用、位图的增长、BITOP 操作的执行时间与频次，以及每日签到请求的吞吐量。通过 Redis INFO、MONITOR、命令统计与应用侧指标结合，可以实时发现异常波动。
常见的告警维度包括：内存使用上限、BITCOUNT 的变化异常、SETBIT/GETBIT 的错误率，以及跨分区的位图聚合耗时。通过这些指标，可以对签到功能的性能瓶颈做出快速响应。
# 获取 Redis 内存使用与关键统计信息
INFO memoryINFO keyspace
