HyperLogLog 近似去重怎么配置或排查

我第一次把 Redis HyperLogLog 用在按天统计独立访客时，最容易误判的不是命令写错，而是把“近似去重”当成了 Set。正确做法是：用一个稳定的时间窗口 key 接收规范化后的标识，用 PFCOUNT 读取估算值；需要跨窗口统计时，再明确选择临时并集还是持久合并。它适合看趋势和规模，不适合要求逐个列出、必须精确对账的名单。

官方文档：https://redis.io/docs/latest/develop/data-types/probabilistic/hyperloglogs/

先把统计窗口和写入对象定清楚

不要把所有日期都写进一个无期限 key。按天、小时或活动周期命名，才能解释数字，也方便过期清理。用户标识还要先统一格式，例如大小写、前后空格和租户前缀，否则同一个人会被编码成多个元素。

redis-cli
# 用独立窗口写入规范化后的访客标识，避免把原始隐私字段直接当作业务明细
PFADD hll:visit:2026-09-13 tenant-a:user-001 tenant-a:user-002
# 读取这个窗口的近似独立数
PFCOUNT hll:visit:2026-09-13
# 生产环境按业务保留周期设置过期时间，示例值按实际口径调整
EXPIRE hll:visit:2026-09-13 172800

PFCOUNT 结果异常时，先查语义再查参数

如果结果为 0，先看 key 是否真的收到写入、窗口是否写错、是否已经过期；不要因为 key 类型显示为 string 就改用 GET 读取成员。HLL 以 Redis string 形式存储，但内部内容不是可枚举的用户集合。

redis-cli
# 这两个检查只确认 key 的存在形态和生命周期，不会列出 HLL 成员
TYPE hll:visit:2026-09-13
TTL hll:visit:2026-09-13
# 用固定样例检查重复写入不会被当成两个人
PFADD hll:debug:sample user-x user-x
PFCOUNT hll:debug:sample

多窗口统计要分清临时并集和持久合并

PFCOUNT key-a key-b 返回的是多个 HLL 的近似并集，适合偶尔查询；它不会创建一个可复用的并集 key。若日报、看板会反复读取同一组窗口，可以用 PFMERGE 写入目标 HLL，再对目标 key 做单 key 计数。

redis-cli
# 临时计算两个窗口的并集，结果仍然是近似值
PFCOUNT hll:visit:2026-09-12 hll:visit:2026-09-13
# 需要复用时把多个窗口合并到一个目标 HLL
PFMERGE hll:visit:week hll:visit:2026-09-12 hll:visit:2026-09-13
# 后续看板只读取合并结果
PFCOUNT hll:visit:week

排查性能时尤其注意窗口数量：单 key PFCOUNT 平均接近常量时间，多 key 查询需要合并参与的 HLL；PFMERGE 也会随输入 sketch 数量增加。把每次看板请求都改成几十个 key 的并集，并不会因为命令短就变成免费操作。

哪些场景不该用 HyperLogLog

它回答的是“有多少个不同元素”，而不是“哪些元素出现过”。需要导出用户清单、撤销某个用户、按用户分组、精确财务结算时，应该保留 Set、明细表或离线数仓；可以同时维护 HLL 做快速概览。还要固定 hash 输入口径，避免今天写用户 ID、明天写设备 ID，造成数字看起来合理却无法比较。

常见问题

PFADD 返回 0 是不是写入失败？

不一定。它表示这次写入没有改变 HLL 的内部寄存器，重复值返回 0 很正常；要判断 key 是否存在和类型，应单独使用 TYPE。

HyperLogLog 能不能查询某个用户是否存在？

不能。HLL 不保存可枚举成员，存在性判断应使用 Set、Bloom Filter 等匹配该需求的数据结构。

为什么 PFCOUNT 多个 key 比单个 key 慢？

多 key 调用需要即时计算这些 HLL 的并集，不能直接复用单 key 的计数缓存；固定报表可用 PFMERGE 生成复用的目标 key。

近似值和真实值差一点要不要立刻修复？

先看业务容忍度和长期偏差。趋势看板通常可以接受估算；对账、计费和名单类任务则应换成能提供精确明细的数据结构。