Redis HyperLogLog 统计 UV 为什么不能做精确去重：误差、按天拆分与 PFCOUNT 验证

运营看板上显示昨天有 100 万 UV，导出用户明细却只有 99 万多。第一反应往往是埋点丢了，但如果统计链路用了 Redis HyperLogLog，这个差异可能只是估算误差。HyperLogLog 的价值是用极小内存估计基数，不是保存用户集合；把它拿去回答“这个用户是否已经领取过优惠券”，结果就会从可接受的统计误差变成业务事故。

不要把 HyperLogLog 当精确去重容器用：它天生不存储原始元素，只能输出误差可控的近似总数，所有需要判断单个用户是否存在的强校验场景，都不能直接依赖它的结果。

问题现场：看板人数和明细人数对不上

先用最小数据复现，不要直接去改采集脚本：

redis-cli DEL uv:20260809
redis-cli PFADD uv:20260809 user-101 user-102 user-103 user-101
redis-cli PFCOUNT uv:20260809
redis-cli TYPE uv:20260809

PFADD 返回值只表示内部基数结构是否发生变化，PFCOUNT 返回的是估算值，TYPE 会显示 string，但这并不意味着它是一个可以用 GET 取出用户列表的普通字符串。HyperLogLog 的内部编码对调用方不可枚举。

HyperLogLog 为什么省内存，却不能查成员

HyperLogLog 记录的是哈希后数据的统计特征，目标是估计不同元素的数量。它保留了“有多少种”的信息，却没有保留“具体是哪几个”的信息。于是下面这类接口没有实现基础：

// 错误的业务假设：HLL 能回答成员查询
if redis.PFCount(ctx, "uv:20260809").Val() > 0 {
    // 这只能说明集合有基数，不能说明 user-101 在里面
}

如果业务要求“同一个账号今天只能领一次”，就不能把 PFCOUNT > 0 当成存在判断。这里的判断方向完全不同：看板关心误差很小的总量，权益系统关心一个 ID 是否精确出现。

先把统计口径拆成按天 key

线上更容易出错的不是命令本身，而是 key 口径。建议把日期和业务范围写进 key，例如：

uv:web:20260809
uv:app:20260809
uv:campaign:618:20260809

这样日报直接执行 PFCOUNT uv:web:20260809，跨天统计再用 PFCOUNT uv:web:20260808 uv:web:20260809。如果需要长期留存，可以把每天的 HLL 合并到月度 key：

redis-cli PFMERGE uv:web:202608:month uv:web:20260801 uv:web:20260802 uv:web:20260803

PFMERGE 的结果仍然是估算基数，不能因为合并后 key 名字更大就把它理解成精确明细。日期 key 还应设置过期时间，避免无期限堆积：

redis-cli EXPIRE uv:web:20260809 7776000

精确去重和 UV 估算要用两套结构

例如“领取过没有”可以用 SADD claim:20260809 user-101，返回 1 才执行发券；如果只需要防重复而不需要枚举名单，可以使用 SET claim:20260809:user-101 1 NX EX 86400。这两个方案的内存成本更高，但语义是精确的。

上线前用四组数据验证选择是否正确

1. 重复写入同一批 userId，观察 PFCOUNT 是否保持接近原始基数。
2. 准备小集合，用 Set 的精确 SCARD 对比 HLL 的 PFCOUNT，记录误差而不是期待完全相等。
3. 把同一天的数据写入两个来源 key，再用 PFCOUNT key-a key-b 验证交集去重口径。
4. 用同一个 userId 连续请求领取接口，确认幂等 key 或唯一约束只允许一次成功。

如果看板的误差突然变大，先查 key 是否混入了不同业务、哈希输入是否带了随机后缀、以及日报是否误把多个日期合并。不要用“再多采几个字段”来修复 HLL，它不会因此变成可枚举集合。

常见问题

HyperLogLog 适合统计多少用户？

它适合大规模独立访客、设备数和活动触达人数等基数统计。具体业务应通过小样本对照记录误差，不要把“适合大规模”理解成“永远精确”。

PFCOUNT 会修改 Redis 数据吗？

单 key 查询通常只读取结构；多 key 统计会按多个 HLL 做基数计算。若要留下合并结果，应显式使用 PFMERGE，并为目标 key 规划日期和过期策略。

用 Set 统计 UV 就一定更好吗？

Set 能精确去重并查询成员，但每个 userId 都要占用存储，用户量大时成本明显上升。看板用 HLL、关键动作用 Set 或数据库约束，通常是更稳妥的组合。

总结：先问“要总数”还是“要名单”

Redis HyperLogLog 解决的是基数估算，不是成员存储。PFADD、PFCOUNT、PFMERGE 可以让 UV 看板用很小的内存持续运行，但它们不能证明某个用户已经出现。统计趋势和精确权益是两种不同的数据契约，按天拆 key、设置过期，再用 Set 或数据库唯一约束承接精确动作，问题就不会在“看板有一点误差”时扩大成“用户被重复发券”。