Redis Bitmap 原理及亿级用户日活/周活实现

Redis Bitmap 原理及亿级用户日活/周活实现1. 概述本文档详细介绍Redis Bitmap的底层原理、核心特性梳理其典型应用场景并重点阐述基于Bitmap实现亿级用户日活DAU、周活WAU统计的具体方案包括实现逻辑、操作命令、性能优势及注意事项为分布式系统中大数据量统计场景提供参考2. Redis Bitmap 核心原理2.1 底层存储结构Redis Bitmap 并非独立的数据结构而是基于 Redis String 类型封装的位级存储方案。其核心逻辑是将 String 类型的字节byte拆分为单个比特bit以比特为最小操作单位实现高效的空间利用。关键特性每个 Bitmap 对应一个二进制数组数组中每一位bit仅能存储 0 或 1 两个值分别表示“未触发”和“已触发”两种状态底层依赖 String 类型的存储机制String 最大支持 512MB对应最大偏移量offset为 2^32 - 1约42.9亿完全满足亿级、十亿级用户场景操作轻量所有 Bitmap 命令均为原子操作可避免并发场景下的数据错乱适配分布式系统需求。2.2 核心操作命令Bitmap 提供简洁的原子命令覆盖“设置、查询、统计、运算”四大核心场景具体如下表所示命令格式功能说明使用场景SETBIT key offset value设置指定 key 对应 Bitmap 的第 offset 位从0开始计数为 value0 或 1原子操作标记用户行为如访问、签到GETBIT key offset获取指定 key 对应 Bitmap 的第 offset 位的值0 或 1查询用户是否有指定行为如是否签到BITCOUNT key [start end]统计指定 key 对应 Bitmap 中值为 1 的比特数start/end 为可选参数指定字节范围默认统计全部统计日活、签到人数等BITOP op destkey key1 key2…对多个 Bitmap 执行位运算op 支持 AND/OR/XOR/NOT结果存入 destkey统计周活、月活多日数据合并BITPOS key value [start end]查找指定 key 对应 Bitmap 中第一个值为 value0 或 1的比特位偏移量查找首个活跃/未活跃用户2.3 空间占用优势核心亮点Bitmap 最核心的优势是极致的空间利用率其空间占用计算方式如下空间大小MB 最大偏移量offset÷ 8 ÷ 1024 ÷ 1024典型场景测算1亿用户offset 最大为 1亿100,000,000 bit ÷ 8 ÷ 1024 ÷ 1024 ≈ 12 MB10亿用户offset 最大为 10亿1,000,000,000 bit ÷ 8 ÷ 1024 ÷ 1024 ≈ 119 MB42亿用户Bitmap 最大支持约 512 MBString 最大容量。相比其他存储方案如 Set、HashBitmap 在大数据量场景下的空间优势极为明显这也是其能支撑亿级日活统计的核心原因。3. Bitmap 典型应用场景Bitmap 基于“位存储高效统计”的特性适用于“二值状态标记大数据量统计”的所有场景以下是最常用的5类场景3.1 用户签到场景需求记录用户每日签到状态统计每日签到人数、用户累计签到天数。实现方案key 设计sign:yyyyMMdd如 sign:20260226表示2026年2月26日的签到记录offset 设计用户唯一ID确保offset唯一避免冲突状态标记用户签到时执行SETBIT sign:20260226 10001 110001为用户ID1表示已签到统计逻辑每日签到人数用BITCOUNT sign:20260226统计用户累计签到天数可通过查询该用户在多个日期 Bitmap 中的位值GETBIT累加得到。3.2 用户状态标记需求标记用户是否在线、是否激活、是否开通会员等二值状态支持快速查询。实现方案key 设计user:active激活状态、user:online在线状态offset 设计用户唯一ID状态标记用户激活时执行SETBIT user:active 10001 1未激活为0用户上线时设1下线时设0查询逻辑通过GETBIT user:active 10001快速判断用户是否激活无需查询数据库提升响应速度。3.3 黑名单/白名单场景需求维护IP黑名单、用户黑名单如禁止登录、禁止访问支持快速校验。实现方案key 设计blacklist:ipIP黑名单、blacklist:user用户黑名单offset 设计IP转换为整数如将IP地址分段转换为十进制、用户ID标记逻辑将黑名单中的IP/用户ID对应的位设为1正常IP/用户设为0校验逻辑访问时将IP/用户ID转换为offset通过GETBIT校验位值1则拒绝访问0则允许响应时间可达微秒级。3.4 布隆过滤器防缓存穿透需求过滤不存在的key如用户ID、商品ID避免缓存穿透请求穿透缓存直接访问数据库。实现方案基于 Bitmap 实现布隆过滤器将多个哈希函数作用于key得到多个offset将这些offset对应的位设为1校验时对key执行相同的哈希运算若所有offset对应的位均为1则key可能存在若有任意一位为0则key一定不存在优势相比传统Set布隆过滤器空间占用极低1亿条数据仅需十几MB可有效拦截无效请求保护数据库。3.5 亿级用户日活/周活/月活统计核心场景需求统计每日、每周、每月活跃用户数去重支撑产品运营决策要求高效、低内存、秒级响应。核心优势Bitmap 极省内存、统计速度快是互联网公司统计DAU/WAU/MAU的标准方案详细实现见第4章节。4. 亿级用户日活DAU、周活WAU实现方案核心思路利用 Bitmap 位存储特性以“日期”为维度生成 Bitmap标记当日活跃用户周活通过位运算合并多日 Bitmap实现去重统计全程原子操作、秒级响应支持亿级用户规模。4.1 前置准备确保用户ID为唯一整数若为字符串ID需先通过哈希算法转换为唯一整数offset避免offset冲突Redis 版本不低于2.6.0支持 SETBIT 命令的原子性设置生产环境建议使用Redis主从/哨兵集群避免单点故障。补充用户ID哈希转换字符串/UUID转整数offset代码示例实际开发中用户ID可能为字符串如UUID、雪花ID字符串形式无法直接作为offset需通过哈希算法转换为唯一整数。推荐使用 MurmurHash 算法高性能、低碰撞率以下是Java语言完整代码示例可直接复用import org.apache.commons.codec.digest.MurmurHash3;import org.springframework.util.Assert;/**用户ID哈希转换工具类字符串ID - 整数offset适配Bitmap*/public class UserIdHashUtil {/**最大偏移量对应Bitmap最大支持的offset2^32 - 1约42.9亿*/private static final long MAX_OFFSET (1L 32) - 1;/**字符串IDUUID/雪花ID字符串等转换为Bitmap可用的整数offsetparam userId 字符串类型用户ID非空return 唯一整数offset0 ~ MAX_OFFSET*/public static long stringToOffset(String userId) {// 非空校验Assert.notBlank(userId, “userId cannot be blank”);// 使用MurmurHash3算法128位计算哈希值取低32位转为正数long hash MurmurHash3.hash128(userId.getBytes())[0];// 确保offset为非负数哈希值可能为负取绝对值后与MAX_OFFSET取模避免越界return Math.abs(hash) % MAX_OFFSET;}/**测试示例*/public static void main(String[] args) {// 示例1UUID类型用户IDString uuidUserId “f47ac10b-58cc-4372-a567-0e02b2c3d479”;long offset1 stringToOffset(uuidUserId);System.out.println(“UUID用户ID转换后offset” offset1); // 输出示例1234567890// 示例2雪花ID字符串类型String snowflakeUserId “1640995200000123456”;long offset2 stringToOffset(snowflakeUserId);System.out.println(“雪花ID字符串转换后offset” offset2); // 输出示例987654321// 校验offset范围确保在0 ~ MAX_OFFSET之间Assert.isTrue(offset1 0 offset1 MAX_OFFSET, “offset out of range”);Assert.isTrue(offset2 0 offset2 MAX_OFFSET, “offset out of range”);}}关键说明依赖引入上述代码依赖 Apache Commons Codec 包MurmurHash3实现Maven依赖如下commons-codeccommons-codec1.15碰撞优化MurmurHash 碰撞率极低若需进一步降低碰撞风险可采用“双重哈希取模”方式如结合MD5哈希再取模offset范围转换后的offset需控制在 0 ~ 2^32 - 1 之间避免超出Bitmap最大支持范围调用示例用户活跃标记时直接调用工具类转换ID再执行SETBIT命令// 字符串用户ID转换为offsetlong offset UserIdHashUtil.stringToOffset(“f47ac10b-58cc-4372-a567-0e02b2c3d479”);// 执行活跃标记stringRedisTemplate.opsForValue().setIfAbsent(“uv:dau:20260226”, offset, 1, TimeUnit.SECONDS);4.2 日活DAU实现4.2.1 实现逻辑日活定义当日有过访问、操作如登录、浏览、下单的用户去重后的总数。核心逻辑每日生成一个独立的 Bitmap用户活跃时标记对应位为1当日结束后统计 Bitmap 中1的个数即为当日DAU。4.2.2 具体操作key 设计uv:dau:yyyyMMdd如 uv:dau:20260226表示2026年2月26日的日活 Bitmap活跃标记用户触发活跃行为如登录时执行原子命令# offset 为用户唯一整数ID字符串ID需通过上述工具类转换1表示活跃SETBIT uv:dau:20260226 10001 1说明同一用户当日多次活跃多次执行 SETBIT 命令不影响结果位值从1设为1无变化天然实现去重。DAU 统计当日任意时间或次日凌晨执行统计命令秒级返回结果# 统计20260226当日活跃用户数去重BITCOUNT uv:dau:20260226数据清理可保留近30天的日活 Bitmap用于周活、月活统计超过30天的可定期删除如通过Redis过期时间自动清理避免占用过多内存。4.2.3 性能测算亿级用户场景单个日活 Bitmap 占用约12MB内存SETBIT 命令QPS支持10万满足高并发场景BITCOUNT 命令统计亿级数据仅需毫秒级完全满足运营统计需求。4.3 周活WAU实现4.3.1 实现逻辑周活定义近7天自然周或滚动7天有过活跃行为的用户去重后总数。核心逻辑利用 Bitmap 的 OR 位运算多个 Bitmap 中任意一个 Bitmap 的对应位为1结果即为1合并近7天的日活 Bitmap合并后的 Bitmap 中1的个数即为周活。4.3.2 具体操作依赖资源近7天的日活 Bitmap如 uv:dau:20260220 至 uv:dau:20260226合并 Bitmap执行 BITOP OR 命令将7天的日活 Bitmap 合并为一个新的 Bitmap# 合并20260220-20260226的日活数据结果存入 uv:wau:20260220-20260226BITOP OR uv:wau:20260220-20260226 uv:dau:20260220 uv:dau:20260221 uv:dau:20260222 uv:dau:20260223 uv:dau:20260224 uv:dau:20260225 uv:dau:20260226说明OR 运算天然实现去重——同一用户只要任意一天活跃对应位为1合并后该位仍为1无需额外去重逻辑。WAU 统计执行 BITCOUNT 命令统计合并后 Bitmap 中1的个数# 统计20260220-20260226的周活用户数BITCOUNT uv:wau:20260220-20260226滚动周活实现若需统计“近7天滚动周活”如当日往前推6天则每日合并“当日前6天”的日活 Bitmap覆盖原有滚动周活 key 即可。4.3.3 性能优化合并时机避免高峰时段合并建议在每日凌晨日活数据稳定后执行合并操作减少对业务的影响内存优化合并后的周活 Bitmap 可设置过期时间如1天避免长期占用内存集群优化若Redis为集群模式确保7天的日活 Bitmap 落在同一节点通过key哈希分片控制避免跨节点位运算导致的性能损耗。4.4 月活MAU实现实现逻辑与周活完全一致仅需将“7天日活 Bitmap”替换为“当月所有日活 Bitmap”执行 BITOP OR 合并后再用 BITCOUNT 统计即可。示例命令合并202602月份所有日活数据统计月活BITOP OR uv:mau:202602 uv:dau:20260201 uv:dau:20260202 … uv:dau:20260228BITCOUNT uv:mau:202602注意当月天数根据实际月份调整合并时需包含当月所有日期的日活 Bitmap。5. 方案对比与优势5.1 与其他统计方案对比实现方案优点缺点适用场景MySQL 去重统计实现简单无需额外组件亿级数据查询极慢全表扫描去重易导致数据库宕机小数据量万级以下统计Redis Set 存储活跃用户实现简单支持快速去重内存占用极高1亿用户约需1GB高并发场景性能下降百万级用户统计Redis Bitmap极省内存亿级12MB/天、统计速度快毫秒级、原子操作、支持高并发需将用户ID转换为整数offset不支持非整数ID直接使用亿级、十亿级用户日活/周活/月活统计签到等场景5.2 Bitmap 方案核心优势空间高效亿级用户日活仅需12MB远优于Set、MySQL方案性能优异SETBIT、BITCOUNT、BITOP 均为原子操作毫秒级响应支持高并发天然去重同一用户多次活跃仅标记一次无需额外去重逻辑易于扩展支持周活、月活等多维度统计仅需简单位运算维护成本低命令简洁无需复杂逻辑可结合Redis过期时间自动清理历史数据。6. 生产环境注意事项用户ID处理确保用户ID为唯一整数若为字符串ID如UUID需通过哈希算法如MurmurHash转换为整数避免offset冲突转换时需注意哈希碰撞可通过双重哈希优化代码示例见4.1节。Redis 集群适配若使用Redis集群需确保同一维度的 Bitmap如同一周的日活 Bitmap落在同一节点避免跨节点位运算导致的性能损耗可通过key前缀哈希分片控制节点分配。过期时间设置日活 Bitmap 可设置30天过期时间周活、月活 Bitmap 可设置1天过期时间避免历史数据占用过多内存过期时间建议在生成key时通过 EXPIRE 命令设置。并发安全所有 Bitmap 命令均为原子操作无需额外加锁但需注意用户ID转换的唯一性避免不同用户映射到同一offset导致统计错误。性能监控生产环境需监控 Bitmap 相关命令的执行耗时如 BITOP 合并大量数据时的耗时避免影响Redis整体性能可通过Redis监控工具如RedisInsight实时监控。降级方案若Redis集群故障可临时降级为“抽样统计”如抽样10%用户避免统计功能完全不可用故障恢复后再补全统计数据。7. 总结Redis Bitmap 是基于 String 类型的位级存储方案核心优势是空间利用率极高、操作原子高效适用于二值状态标记和大数据量统计场景。其中亿级用户日活、周活、月活统计是其最典型的应用通过“每日Bitmap标记位运算合并”的方式实现了高效去重、秒级统计且内存占用极低是互联网公司产品运营统计的首选方案。生产环境落地时需重点关注用户ID转换、Redis集群适配、过期时间设置等细节确保统计数据准确、服务稳定。同时Bitmap 也可结合其他Redis特性如布隆过滤器进一步拓展其应用场景提升分布式系统的性能和可靠性。