Redis用HyperLogLog统计UV实现快速去重

Redis 的 HyperLogLog（HLL）是统计日活 UV 的高效方案，以仅约 12KB 的固定内存和 O(1) 时间复杂度支撑亿级去重，但需接受约 0.81% 的相对误差，且完全不支持成员查询、精确交集或验证单个用户是否存在；实际落地时必须按日期分 key（如 uv:20240520）、设置合理过期、统一用户标识，并避开 PFMERGE 累积误差等常见陷阱——它不是万能替代品，而是在精度让渡换取极致性能与扩展性时的明智之选。

HyperLogLog 适合统计 UV 吗？——是，但只在特定场景下

直接说结论：HLL 是 Redis 中统计日活 UV 的合理选择，前提是「你接受 0.81% 左右的相对误差」且「不需要知道具体有哪些用户」。它不存原始 ID，只存概率性摘要，内存固定约 12KB/结构，哪怕亿级去重也扛得住。但如果你要查某天某个 user_id 是否来过，或者要做交集（比如「连续两天都来的用户」），HLL 就无能为力了——它不支持成员查询，也不支持精确交并差。

每天一个 pfadd + pfcount 就够了吗？——得看怎么分 key

常见错误是把所有用户往一个 key 里塞，比如全用 uv:2024，这样没法按天查。正确做法是按日期分 key，例如：

PFADD uv:20240520 user_123 user_456 user_123

注意：PFADD 自动去重，重复 user_id 不影响结果。第二天换 key：uv:20240521。这样 PFCount uv:20240520 就是当天 UV。别用时间戳当 key 后缀（如 uv:1716220800），可读性差、运维困难。

• key 命名建议带业务前缀，比如 app:web:uv:20240520，避免和其他项目冲突
• 如果需要周 UV 或月 UV，不要用 PFMERGE 拼接多天——它会放大误差；改用单独维护一个 uv:week:2024W21 key，每天 PFADD 进去
• PFADD 是原子操作，高并发写没问题；但别在单次调用里塞几万个 ID，拆成每批 ≤ 1000 个更稳

为什么不用 SET 或 Bitmap？——内存和扩展性卡死你

用 SET 存百万用户 ID，每个 ID 平均占 32 字节（字符串开销+指针），1000 万就是 300MB+，还不能持久化大 key；Bitmap 要求 ID 是纯数字且连续或可映射，实际业务中 user_id 往往是 UUID 或带前缀字符串，硬转会稀疏、浪费空间。而 HLL 无论 ID 长短、格式，一律压缩成 12KB，且 PFCount 时间复杂度是 O(1)。

不过要注意：如果日活长期低于 1000，HLL 的误差可能比真实值还“跳”，这时反而不如用 SET（内存占用小，精度高）。

上线前必须验证的三个坑

刚切到 HLL 统计时，最容易栽在这三处：

• 客户端没做 key 过期：EXPIRE uv:20240520 86400 必须配，否则旧 key 积压，Redis 内存涨到报警
• 漏掉多端重复：用户用 App 和 H5 同一天访问，user_id 可能不同（App 用 device_id，H5 用 cookie_id），HLL 会算成两人——得在上游统一对齐标识，比如都用 fingerprint
• PFCount 返回的是估算值，别拿它直接展示「精确到个位」的数字，前端显示建议加个「约」字，或后端返回时附带误差说明字段

误差本身不可控，但可以测：用已知 10 万不重复 ID 跑一次 PFCount，看偏差是否在 800 以内。超出就该查数据接入逻辑有没有误塞空值或乱码。

今天关于《Redis用HyperLogLog统计UV实现快速去重》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！