前段时间一位兄弟去腾讯面试回来跟我说他挂在了一道「签到题」上。面试官问10 亿用户签到记一年给你 1G 内存怎么判断某个用户是否「连续签到 30 天」他开口就是 Bitmap觉得自己答得不错。结果面试官继续追问三句之后他就接不住了。他缺的其实不是 Bitmap 怎么用而是对「这道题到底在考什么」的理解。一、先算一笔账为什么不能硬存10 亿用户每人 365 天如果把每次签到都当作 MySQL 里的一行10 亿 × 365 3650 亿 行按 20 字节 / 行估算3650 亿 × 20 ≈ 6.6 TB6.6 TB别说 1G普通单机都扛不住。但签到这个数据有个天然特性它只有「签了」和「没签」两种状态。一个 bit 就能表达不需要整行。365 天 365 bit 46 字节 / 人 / 年10 亿用户全量46 字节 × 10 亿 ≈ 43 GB43 GB 依然要分片但它已经从「做不了」变成了一道普通的容量题。二、第一个坑BITCOUNT 算不出「连续」很多人一听到 Bitmap马上想BITCOUNT 一下不就知道 30 天里签了多少天吗但 BITCOUNT 只能告诉你「总数」不能告诉你「连续」。假设 30 天里有 30 个 1但它们分别是月初 15 天、月末 15 天中间断了——BITCOUNT 会开心地返回 30但用户根本没连续签到。所以这道题的真正考点不是「会不会用 Bitmap」而是拿到 46 字节之后你怎么在本地判断连续性。三、第二个坑key 按哪个维度切同样是 43 GB两种存法查询能力天差地别。维度按「天」存按「用户」存key 示例sign:20260802sign:u10086:2026offset 含义uidday_of_year单个 key 大小10 亿 bit ≈ 119 MB365 bit ≈ 46 字节擅长的查询今天多少人签到小强连签 30 天了吗不擅长的查询某人连续 30 天签到 → 30 次网络往返今天总签到人数 → 遍历 10 亿 key面试官问「怎么算连续 30 天」其实是在问你的 key 按哪个维度切。答案是按用户存。因为「连续签到」天然是单人维度的查询一次 GET 就把一整年的 46 字节取回来。四、正确做法一次 GET本地扫描拿到 46 字节后最简单的方法就是本地扫一遍。365 次循环CPU 纳秒级完成。# Java 示例最长连续签到天数public int maxConsecutiveDays(byte[] bits) {int max 0, cur 0;for (int i 0; i 365; i) {int b (bits[i / 8] (i % 8)) 1;if (b 1) {cur;max Math.max(max, cur);} else {cur 0;}}return max;}如果只想判断「是否存在连续 30 天」可以用位运算技巧五次移位就能出结果x x 1;x x 2;x x 4;x x 8;x x 14;// 五步之后还非零就说明存在连续 30 个 1这五步的位移量不是各自独立生效而是累加的——每一步都在「上一步已确认的长度」基础上再往外扩。把累计值摊开看步骤本步位移累计位移能确认的连续111≥ 2223≥ 4347≥ 84815≥ 1651429≥ 30原理是每次把相邻的 1 压缩成一个「连续段标记」五步之后如果还有非零位就一定存在长度 ≥30 的连续 1。五、那按天存的 Bitmap 是不是就没用了不是。两种维度服务不同的查询按用户存查「某人连续签到多久」「某人哪天签了」——单人维度。按天存查「今天全站签到人数」「连续 N 天全勤的用户有哪些」——全站维度。大厂的真实答案通常是两份都存。按用户的版本放在缓存层支撑实时查询按天的版本用于运营统计、离线分析。有人问用 BITOP AND 把 30 个按天的 bitmap 做与运算不也能找出连续签到的人吗技术上可以但每个 key 119 MB30 个 key 就是 3.5 GBRedis 单线程会阻塞几百毫秒甚至秒级——线上不敢跑。六、Redis 里怎么落盘写入时只需要一行SETBIT sign:{uid}:{year} {day_of_year} 1读取时一次 GETGET sign:{uid}:{year}然后交给本地代码去判断连续性。Redis 只负责存取不做滑动窗口计算。跨年问题也好处理如果当前日期在 1 月初「最近 30 天」会跨到去年读两个 key 拼起来即可。七、常见翻车答案答案问题MySQL 一行一条签到记录6.6 TB查询和存储都扛不住Redis List / Set 存日期每人 365 条记录内存约 1.4 TBBITCOUNT 判断连续只能算总数不能判断连续性BITOP AND 在线执行3.5 GB 数据在单线程 Redis 上阻塞只按天存 Bitmap单人连续签到要 30 次网络往返八、面试官大概率会追问的变体1如果要看「累计签到次数」能不能继续用 Bitmap可以但 Bitmap 只能表达 0/1累计次数需要 HyperLogLog 或一个额外的计数器。2如果签到数据很稀疏99% 的人不活跃Bitmap 会不会浪费会。稀疏场景下 Roaring Bitmap 比普通 Bitmap 省得多这是工程上的进阶选项。3如果要发「连续签到 30 天」的奖励怎么保证幂等不能靠判断连续就发奖必须用另一个 key 记录「该用户是否已领取」否则重试会多发。4如果内存再砍一半只剩 256MB怎么办用哈希分桶 外部排序把 QQ 号或 uid 哈希到不同文件分桶去重/分桶统计。九、面试标准答案模板直接背诵上面八节是原理这一节是你能直接背进面试的话术。面试官问到「连续签到」照着这五步走第一步 · 选型签到只有「签了 / 没签」两种状态用 Bitmap。每人每年 365 bit 46 字节全量 43 GB比 MySQL 硬存的 6.6 TB 少了约 159 倍。这是存储层面的结论。第二步 · 定 key 维度这道题问的是「某个用户连续 30 天」所以按用户存sign:{uid}:{year}offset 用 day_of_year。一次 GET 取回 46 字节本地就能算单人连续。按天存适合全站统计不适合这道题。第三步 · 主动避坑BITCOUNT 只能算「总天数」算不出「连续」。所以我不靠 BITCOUNT 判断连续避免被追问时接不住。第四步 · 给具体算法GET 回来 46 字节后在本地扫一遍365 次循环纳秒级。如果只判断「是否存在连续 30 天」用五次移位x x1/2/4/8/14结果还非零就存在连续段。Redis 只负责存取不在线上做滑动窗口计算。第五步 · 补工程闭环线上通常两份都存按用户的做实时查询按天的做运营统计跨年就读两个 key 拼起来。奖励发放用独立 key 保证幂等避免重试多发。背这一套的价值它同时覆盖了「存储」「key 设计」「避坑」「算法」「工程闭环」五个层次面试官不管往哪个方向追你都有下一句接住。Bitmap 不是数据结构的高招而是「把业务语义压进 bit」的抽象能力。真正决定答案质量的不是你调用了哪个 Redis 命令而是你能否一眼看出这道题考的是 key 的维度选择。