hyperloglog适合uv统计的核心原因是其以12kb固定内存、约0.81%误差率高效估算大规模去重基数，优于set的内存爆炸和bitmap对id范围的强依赖；需按天分key存储、用稳定标识、禁用复用与删除，并配合expire管理生命周期。

HyperLogLog 适合 UV 统计的核心原因

Redis 的 HLL 不是精确计数器，而是概率型数据结构，用 12KB 固定内存估算集合基数，误差率约 0.81%。对 UV 这类“只关心“有没有来过”，不关心“来了几次”且量级常达千万/亿”的场景，它比 SET（存所有 ID 内存爆炸）或 Bitmap（需要预设用户 ID 范围）更实用。

PFADD 和 PFCOUNT 的正确调用姿势

UV 统计本质是「按天/按渠道聚合去重」，不是单次插入就完事。必须注意：同一个用户在同一天多次访问，只应 PFADD 一次；不同天要分 key 存储，否则无法回溯历史。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 每天生成独立 key，例如：uv:20240520、uv:20240521
• 用户标识建议用稳定字段，如登录态 user_id 或设备指纹 device_id，避免用会变的 session_id
• 写入时直接传入字符串，无需 base64 或 hash 预处理：PFADD uv:20240520 "u1001"
• 读取当天 UV：PFCOUNT uv:20240520；合并多天（如最近 7 天）：PFMERGE uv:week uv:20240514 uv:20240515 ... uv:20240520，再 PFCOUNT uv:week

常见踩坑点：精度、内存、误用场景

HLL 不支持删除元素，也不支持获取具体成员列表——它天生就是为“只增不删+只问总数”设计的。一旦误用，问题会隐蔽且难排查。

• 把 HLL 当 SET 用：比如想查“哪些用户今天来了”，这是做不到的，PFCOUNT 只返回数字
• key 复用错误：用同一个 key 累加多日数据，会导致后续无法拆分，且 PFCOUNT 结果是累计值而非单日值
• 低估误差影响：当真实 UV 小于 100 时，HLL 误差可能达 ±10；此时不如直接用 SET + SCARD
• 内存看似小，但 key 数量多时仍需留意：每个 HLL key 占 12KB，10 万个日粒度 key 就占 1.2GB 内存

和 Bitmap 方案对比时的关键决策点

如果用户 ID 是连续整数且范围可控（比如 1~1 亿），Bitmap（用 SETBIT）能实现 0 误差、更低内存（1 亿 bit ≈ 12MB）。但现实业务中，ID 往往是字符串、UUID 或稀疏整数，这时 HLL 是更稳妥的选择。

• 选 HLL：ID 类型杂、无全局唯一整数编号、需要快速上线、能接受 ~0.8% 误差
• 选 Bitmap：ID 可映射为紧凑整数、有离线 ID 映射服务、对误差零容忍、UV 量级稳定在亿以内
• 别选 SET：UV 过百万后，内存和 SCARD 延迟都会明显上升，Redis 官方明确不推荐用于超大集合去重

实际部署时，最易被忽略的是 key 的生命周期管理——没有定期 EXPIRE 或定时清理过期 key，久而久之冷数据堆积，内存只增不减。记得给每个 uv:YYYYMMDD key 设置 EXPIRE，比如保留 90 天：EXPIRE uv:20240520 7776000。