Redis 统计 UV 怎么用 HyperLogLog：误差和适用场景

做日 UV 时，最容易踩的坑不是命令不会写，而是把“去重统计”和“明细保存”混成一件事。Redis HyperLogLog 适合只关心一个时间窗口内大概有多少个不同访问者的场景：用 PFADD 记录标识，PFCOUNT 读取估算值，跨渠道或分片时用 PFMERGE 合并。它牺牲精确性换取很小且稳定的内存占用，不能拿来回答“具体是哪几个用户访问过”。

先把 UV 的去重边界设计清楚

UV 统计的第一步不是选命令，而是定义“一个人”在系统里对应什么标识。登录站点通常使用稳定的 user_id；未登录页面可以使用经过合规处理的匿名设备标识。IP 既可能被多人共享，也可能涉及隐私和合规风险，不应该未经评估就直接作为长期统计元素。

日 UV 建议把页面、窗口和时区固定在 key 中。比如页面 42 在中国时区 2026 年 9 月 5 日的 key 可以写成：

page:42:uv:2026-09-05

这样做的好处是当天查询不会混入昨天的数据，渠道拆分也有明确位置。若业务按自然日结算，应用层生成日期时要统一时区；不要让不同服务各自用机器本地时间拼 key。

PFADD 和 PFCOUNT 怎么配合统计一次访问

收到一次页面访问后，把去重标识写进当天的 HLL；需要展示看板时读取它的近似基数。下面的命令只演示数据关系，u-1001 和 u-1002 是业务层已经确定的标识：

PFADD page:42:uv:2026-09-05 u-1001
PFADD page:42:uv:2026-09-05 u-1002
PFADD page:42:uv:2026-09-05 u-1001
PFCOUNT page:42:uv:2026-09-05

同一个标识重复写入不会按访问次数累加，所以它表达的是去重人数而不是 PV。需要注意的是，PFADD 的返回值表示内部寄存器是否发生改变，并不是“新增了一个确定用户”；PFCOUNT 返回的是近似基数，不能把它当成精确名单。

PFMERGE 适合合并渠道，不是把数字直接相加

如果移动端、Web 端和小程序分别写入 HLL，不能把三个 PFCOUNT 的结果相加，因为同一用户可能同时出现在多个渠道。正确做法是保留各渠道的源 key，再把它们合并到一个目标 key：

PFMERGE page:42:uv:2026-09-05:all \
  page:42:uv:2026-09-05:web \
  page:42:uv:2026-09-05:app
PFCOUNT page:42:uv:2026-09-05:all

合并结果仍然是近似的跨源去重人数。Redis 文档把单键的写入和读取描述为常数时间与常数空间；合并多个 HLL 时，成本随参与合并的草图数量增长。因此可以让渠道或分片各自写入，再在看板刷新、小时汇总或离线任务中合并，避免每个请求都扫描全部来源。

误差能不能接受，决定是否应该用 HyperLogLog

Redis 文档给出的实现标准误差约为 0.81%，最坏情况下占用约 12 KB，实际数据较少时可能更小。这个特性适合趋势看板、内容热度、搜索词去重和活动 UV 等“量级正确、成本稳定”场景。它不是承诺每次结果都偏小或偏大 0.81%，而是统计意义上的标准误差，业务应结合样本规模和报表容忍度评估。

最后再检查三个工程细节：窗口 key 是否有明确过期策略，来源标识是否已经脱敏，报表是否把近似数标注为估算值。若一天一个 key，可以按业务保留周期设置 TTL；但不要在还要合并历史窗口时过早删除源 key。

相关问题

HyperLogLog 能不能查询具体有哪些用户？

不能。它保存的是用于估算基数的状态，不提供成员枚举能力。需要名单时必须另外保存 Set、明细表或日志索引。

PFCOUNT 多个 key 会得到精确总人数吗？

它会对多个 HLL 做合并意义上的估算，结果不是各 key 计数的简单相加，也不是精确总人数。跨渠道去重时优先显式使用 PFMERGE 保存统一结果。

小规模 UV 也必须用 HyperLogLog 吗？

不必须。规模小且需要成员查询、删除或精确审计时，Set 往往更直观；HLL 的价值主要在于规模增长后仍能以有限内存提供近似基数。