Redis HyperLogLog用近似结构估算去重计数的实现方法

做日活、活动触达人数或设备去重时，直接把每个用户 ID 放进 Redis Set 很直观，但内存会随成员数增长，而且跨天、跨分片合并时还要处理大量明细。Redis HyperLogLog 用固定上限的概率结构保存基数估计：官方文档给出的标准误差是 0.81%，最坏约占 12 KB。它适合“人数趋势”和“覆盖规模”这类允许小误差的指标，不适合订单金额、余额或必须列出成员的业务。

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

先把 HyperLogLog 的适用边界定清楚

Set 保存真实成员，能回答“这个用户是否出现过”和“列出全部成员”；HyperLogLog 只保留用于估算基数的内部状态，不能反查具体用户。两者的选择取决于结果用途：如果报表只需要“约有多少个独立访客”，HLL 可以用很小且稳定的空间换取近似结果；如果要导出名单、做精确风控或按成员删除，就必须保留明细结构。

用 PFADD 和 PFCOUNT 完成单个周期的去重估算

实践中可以按日期或业务维度拆 key，例如 uv:20260920。同一个用户在同一个 HLL 中重复写入不会按成员列表累加；PFADD 返回 1 只表示内部寄存器发生了变化，返回 0 不等同于“这个值一定已经被精确记录”。读取时使用 PFCOUNT：

# 用日期隔离统计窗口；同一用户重复出现仍由 HLL 近似去重
PFADD uv:20260920 user:1001 user:1002 user:1001

# 读取当前窗口的近似独立用户数
PFCOUNT uv:20260920

# 返回值是近似基数，不要把它当成用户明细或精确财务数字

工程上要先统一输入口径：同一个用户应先映射为稳定的业务 ID，不能今天写手机号、明天写设备临时 ID，否则统计的是不同实体。日期 key 也要配合过期策略或归档策略，避免业务已经结束但 key 永久增长。

多分片合并要用 PFMERGE，不能直接相加

假设上午和下午、华东和华南各有一个 HLL，两个集合可能包含同一批用户。直接把两个 PFCOUNT 相加，会把重复用户算两次。PFMERGE 会把多个 HLL 的内部状态合并到目标 key，再由 PFCOUNT 读取整体近似值：

# 两个来源各自记录用户，不在应用层保存成员明细
PFADD uv:morning user:1001 user:1002 user:1003
PFADD uv:evening user:1002 user:1004

# 目标 key 独立保存合并结果，避免覆盖来源窗口
PFMERGE uv:all uv:morning uv:evening

# 结果应接近 4，而不是两个局部计数的简单相加
PFCOUNT uv:all

官方命令参考把单 key 的 PFCOUNT 标为平均常数时间，把多 key 统计和 PFMERGE 标为随 key 数量增长的操作。因此分片很多时，更稳妥的方式是按小时或批次合并到固定的汇总 key，而不是每次请求都把所有历史 key 作为参数传入。源 key 与目标 key 还应采用明确命名，避免把不同口径的用户 ID 混在一起。

上线前用误差和业务结果做最后判断

HyperLogLog 的“0.81%”应理解为长期统计意义上的标准误差，不能拿一次小样本的输出反推固定误差上下限。上线前可以保留一小段低流量样本，用 Set 或离线精确集合做对照，观察趋势和误差是否满足业务容忍度；生产主链路仍使用 HLL，避免为全量流量保存明细。

• 能接受近似：UV、去重设备数、内容覆盖人数、活动触达规模。
• 不能接受近似：扣款、库存、积分、审计清单、需要按成员删除的集合。
• 要注意合并：统一用户标识、周期口径和 key 命名，先合并再计数。

常见问题

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

不能。它保存的是估算基数所需的状态，不提供成员枚举和可靠的单成员查询；需要这类能力时选择 Set 或明细存储。

PFADD 返回 0 是不是说明用户重复？

只能说明这次写入没有改变内部寄存器，不能把它当成精确的成员存在性证明。业务判断应以基数指标为主。

多个 HyperLogLog 可以直接把 PFCOUNT 相加吗？

不建议。来源之间存在重复时会重复计数；用 PFMERGE 合并后再 PFCOUNT，结果仍是近似值但口径正确。