1.

引言

签到功能几乎是现代互联网应用的标配：从电商APP的每日签到领积分，到学习社区的连续打卡记录，再到健身应用的锻炼打卡。

这个看似简单的功能，背后却涉及数据存储、高并发处理、连续签到计算等一系列技术决策。

其中，最基础也是最核心的问题就是：数据该存哪里？

开发者常常在关系型数据库

MySQL

性能极高、数据结构灵活。

本文将围绕签到功能，从需求分析出发，深入探讨两种存储方案的实现细节、优缺点对比，并给出不同场景下的最佳实践，全文约

万字，希望能帮助你彻底理清这个“小功能”背后的“大学问”。

2.

签到功能的核心需求分析

在设计签到系统之前，我们需要明确它通常要满足哪些业务需求。

一个典型的签到功能包括：

2.1

基础功能

• 用户签到：用户每天只能签到一次，重复签到需进行防重处理。

• 签到记录：记录用户的签到时间，通常精确到天。

• 签到历史查询：用户可以查看自己某个月或某段时间的签到情况（如日历形式）。

• 连续签到统计：计算用户当前连续签到的天数，用于发放奖励。

• 积分/奖励机制：根据连续签到天数给予不同积分或虚拟物品。

2.2

非功能性需求

• 高并发：签到通常发生在特定时间点（如凌晨0点），容易产生瞬时高并发。

• 数据一致性：签到不可丢失，积分发放需准确。

• 扩展性：随着用户量增长，系统应能水平扩展。

• 成本：存储成本和开发运维成本需在可控范围。

这些需求将直接影响我们对数据库的选择。

3.

MySQL

作为传统关系数据库，凭借其事务支持和丰富的查询能力，是许多项目的首选。

下面我们逐步分析如何用

MySQL

表结构设计

最简单的签到表设计如下：

sql

CREATE
TABLE
(`user_id`,`sign_date`),
KEY
CHARSET=utf8mb4;

说明：

• 使用联合唯一索引uk_user_date保证每个用户每天只能签到一次。

• 索引idx_user_id和idx_sign_date用于加速查询。

• points字段记录本次签到获得的积分，可根据连续规则动态计算。

3.2

签到操作

用户签到时，需要插入一条记录。

但由于唯一索引的存在，重复签到会抛出异常，因此通常使用INSERT

...

UPDATE或先查询再插入。

3.2.1

插入或忽略

sql

INSERT
IGNORE
IGNORE会在违反唯一约束时静默忽略，返回影响行数为0。
程序可通过影响行数判断是否签到成功。
3.2.2
先检查后插入（事务）
为了保证积分计算的正确性，有时需要先查询当天是否已签到，再决定是否插入，同时计算连续天数和积分。
sql
START
TRANSACTION;
UPDATE加行锁可以防止并发插入，但会降低并发性能。
对于签到场景，大多数情况下INSERT
查询签到历史
要展示某个月的签到日历，可以查询该月所有签到记录：
sql
SELECT
sign_date
计算连续签到天数
连续签到是签到系统的核心难点。
MySQL
中计算连续签到有多种方法，下面介绍两种常用方案。
3.4.1
使用窗口函数（MySQL
8.0+）
假设我们要计算截至今天（2025-02-16）的连续签到天数。
思路是找到最近一次未签到的日期，然后用今天减去那个日期。
sql
WITH
user_signs
);
逻辑比较复杂，实际应用中更常见的是在业务层通过循环或利用签到表数据计算。
3.4.2
业务层计算
查询用户最近一段时间的签到记录（比如最近30天）。
从今天往前遍历，直到发现断签。
计算连续天数。
示例代码（PHP）：
php
$today
=
}
这种方法简单直接，但在用户连续签到很长时（如几百天），查询数据量可能较大，但一般签到记录不会太多（一年也就365条），性能可接受。
3.5
优化建议
分区表：按用户ID哈希或按日期范围分区，提高查询和归档效率。
读写分离：签到写多读少，可考虑主从复制，将查询分散到从库。
缓存：连续签到结果可缓存在
Redis
中，减少数据库压力。
3.6
MySQL
实现签到功能的优缺点
优点：
事务支持：保证积分、奖励的一致性。
复杂查询：可方便地统计历史签到、排行等。
成熟稳定：备份恢复、监控工具丰富。
数据持久化：无需担心数据丢失。
缺点：
写入性能：每次签到都是一次插入，随着记录数增长，索引维护成本增加，高并发下可能成为瓶颈。
存储成本：每条记录至少包含用户ID、日期等字段，占用空间较大。
连续计算复杂：需要编写复杂
SQL
或业务逻辑，且随着数据量增大效率下降。
4.
Redis
基于内存，支持多种数据结构，尤其适合计数器、位图等场景。
利用
Redis
Bitmap？
Bitmap（位图）是一种通过位操作来标记状态的数据结构。
在签到场景中，每个用户一年的签到状态仅需
365
字节），存储成本极低，且支持快速位运算。
4.2
Redis
核心命令
SETBIT
key
位的值。
BITCOUNT
key
的位数。
BITFIELD
key
...]：对位图进行多字节操作，适合获取连续位。
BITOP
operation
...]：对多个位图进行与、或、非、异或操作。
4.3
签到功能实现
4.3.1
存储设计
方案一：每个用户一个
key，以日期为偏移量
key
格式：sign:{user_id}:{yyyyMM}
offset：当月第几天（从
开始）
value：1
表示签到，0
表示未签
例如，用户
123
keysign:123:202502中，2
日对应
1，依此类推。
优点：内存占用极小（每月约
位，不到
key。
方案二：每个日期一个
为偏移量
key
格式：sign:{yyyyMMdd}
offset：用户
ID（假设用户
为连续数字或可映射）
value：1
表示该用户当天签到
这种方案适合需要统计当天签到人数、用户签到排行等场景，但用户
不连续时浪费空间，且每个
相关，可能极大。
通常采用方案一。
4.3.2
签到操作
用户签到（假设以月为单位存储）：
bash
#
offset
查询某月签到记录
获取整个月的签到状态：
bash
#
BITFIELD
位的整数，通过位运算或程序解析即可知道每天的签到情况。
如果需要列出具体签到日期，可以遍历每个
offset
使用GETBIT，或者用
Lua
计算连续签到天数
计算截至今天的连续签到天数，需要从当前
offset
为止。
方法一：循环调用
GETBIT
bash
#
伪代码
break
这种方式需要多次网络请求，效率低，可以使用
Lua
脚本优化。
方法二：Lua
脚本
lua
--
KEYS[1]:
count
调用：EVAL
script
15）
方法三：使用
BITFIELD
获取多个位
BITFIELD可以一次获取多个位（例如从
today_offset），然后交给程序计算连续
Redis
返回的是整数，需要解析位模式，可能较复杂。
4.3.5
跨月连续签到
当连续签到跨月时，需要处理上个月的数据。
例如，今天是
日，需要检查
key，继续计算，直到找到断点或达到某个上限（如最大连续天数限制）。
4.4
Redis
持久化，但仍可能丢失少量数据（取决于配置）。
对于签到数据，丢失可能导致用户权益受损，因此需权衡。
RDB：定期快照，两次快照之间的数据可能丢失。
AOF：每秒同步（everysec）最多丢失
秒数据，可接受吗？
混合持久化：Redis
4.0
AOF。
若对可靠性要求极高，可考虑
Redis
实现签到功能的优缺点
优点：
极高读写性能：基于内存，单机
QPS
万+。
存储空间极小：每个用户每年仅需约
字节。
原子操作：SETBIT是原子操作，天然防并发。
丰富位运算：可快速统计月签到次数、多个用户交集等。
缺点：
持久化风险：依赖持久化配置，极端情况可能丢数据。
跨月连续计算稍复杂：需要
Lua
key。
内存占用随用户数线性增长：但相对传统存储依然小得多。
缺乏事务支持：但
Lua
详细对比
维度
MySQL
Redis
(Bitmap)
读写性能
单机几千
I/O
单机
QPS，纯内存操作
存储成本
每条记录约几十字节，一年
365
字节
数据持久化
通过事务、binlog
RDB/AOF
保证最终一致，可能丢数据
复杂查询
支持
SQL，可任意聚合、统计
有限，只能进行位运算，需在客户端处理
连续签到计算
可通过
SQL
脚本极快
并发控制
通过锁或事务，可能影响性能
原子操作，天然支持高并发
扩展性
可通过分库分表扩展，运维复杂
可通过
Redis
扩展，但跨节点计算复杂
开发维护成本
表结构设计、SQL
脚本、内存监控
典型适用场景
中小项目，需要复杂统计，数据一致性要求高
高并发签到，需要快速连续统计，可容忍数据短暂丢失
6.
实际应用场景建议
6.1
小型项目或早期阶段
用户量少（<10万），并发低，可使用
MySQL
简单实现。
优点：开发快，无需引入额外组件，数据绝对可靠。
示例：个人博客的每日签到、内部工具。
6.2
中大型高并发项目
用户量百万级以上，特别是零点峰值明显，推荐使用
Redis
作为主要存储。
优点：扛住高并发，节省存储成本。
需配合持久化策略，并考虑双写到
MySQL
混合方案（最佳实践）
结合两者优点，实现高性能与可靠性并存：
写入路径：
用户签到
Redis（SETBIT成功）
返回签到成功。
同时将签到消息发送到消息队列（如
Kafka/RabbitMQ）。
消费者异步将签到记录写入
MySQL。
读取路径：
查询当天签到状态：直接读
Redis。
查询历史签到或连续天数：优先读
Redis（若数据完整），若
Redis
Redis。
数据一致性：
Redis
个月），确保热数据在内存。
MySQL
作为最终数据源，用于对账和离线统计。
这种架构既保证了签到接口的低延迟，又保证了数据最终一致。
6.4
Redis
方案如何保证数据不丢？
若决定完全依赖
Redis，可采取以下措施：
开启
AOF
持久化，并设置appendfsync
Redis
集群，避免单点故障。
定期将
Redis
数据导出备份（例如用SCAN遍历所有签到
key，存入
或对象存储）。
但必须接受：在极端故障（如机器断电）下，最后
秒的签到可能丢失。
对于签到功能，通常用户可接受偶尔补签，但需提前告知。
7.
深入探讨：连续签到算法的更多细节
7.1
方案中，跨月连续需要合并两个月的数据。
假设今天是
Lua
offset，脚本内先计算当月，若当月第一天为
offset
继续。
考虑性能，可以限制最大连续天数（如
365
天），避免无限循环。
7.2
时区处理
签到通常以自然天为单位，但服务器时区可能与用户不一致。
解决方案：
统一使用
UTC
存储，但按用户时区转换。
Redis
key
中包含日期时，需用用户所在时区的日期。
例如，中国用户使用北京时间YYYYMMDD。
如果使用
UTC
点，导致用户预期不符。
因此强烈建议按用户当地时间记录。
7.3
签到补签与漏签
有些业务允许补签（消耗道具）。
实现时，Redis
可以直接SETBIT修改过去的位，但需注意连续天数重新计算。
若补签导致连续，应在业务层更新连续天数缓存。
7.4
积分发放规则
积分通常与连续天数挂钩，如：连续第
分，第
分。
计算积分可在签到后立即计算，并记录到积分流水表（MySQL
Redis
hash）。
由于积分涉及账户余额，建议最终落地到
MySQL，保证数据一致性。
8.
总结
回到最初的问题：“一个小小的签到功能，到底用
MySQL
Redis？”
答案不是绝对的，取决于你的业务规模、并发要求、团队技术栈和数据一致性需求。
如果你在做一个个人项目或初期产品，用户量小，MySQL
完全足够，简单可靠。
如果你在做一个百万级日活的应用，并且预计签到会成为高频接口，Redis
是更优选择，能轻松应对高并发，且存储成本极低。
如果你追求极致性能和可靠性兼备，可以采用
Redis
的混合架构，各取所长。