pfadd能将uv统计内存从gb级压至12kb，因其不存原始数据，仅用16384个6位寄存器记录哈希前导零最大长度，固定占用约12kb，误差±0.81%。
直接用 PFADD 替代 SADD，用 PFCOUNT 替代 SCARD，就能把 UV 统计的内存从 GB 级压到 KB 级——前提是接受 ±0.81% 的误差。
为什么 PFADD 能省下 99% 内存？
HyperLogLog 不存原始数据，只维护 16384 个“桶”（寄存器），每个桶仅记录哈希后前导零的最大长度（6 bit）。整个结构固定占用约 12KB，和数据量完全无关。
对比来看：
- 存 100 万用户 ID 的
Set：约 80MB（按平均 64 字节/元素估算） - 同量级的
PFADD：始终 ≈ 12KB - 误差控制在 0.81%，即 100 万 UV 里最多偏差 ±8100 人——业务上通常可接受
PFADD 和 PFCOUNT 的实际调用要点
PFADD 是幂等操作：重复添加同一元素不会改变内部状态，返回值为 1 表示有新元素被纳入统计，0 表示已存在或无更新。
PFCOUNT 看似读操作，实则会写缓存：它会在 HyperLogLog 值末尾 8 字节写入最近一次计算出的基数估计值，避免重复计算。所以高并发下对同一 key 频繁 PFCOUNT 可能引发小竞争。
常见误用：
- 把用户 ID 拼接时间戳再
PFADD（如"user_123:20261020"）→ 这会让同一个用户每天都被算作新人，失去去重意义 - 用
PFCOUNT实时查每秒 UV → 应该聚合到分钟/小时粒度，或用定时任务预热缓存 - 误以为
PFADD支持通配符或模糊匹配 → 它只认完整、确定的字符串值
多维度统计必须用 PFMERGE 吗？
不一定。如果只是“全站 UV”，一个 key 就够了；但页面级、渠道级、设备类型级等多维组合，建议分 key 存储，需要汇总时再 PFMERGE。
注意：PFMERGE 是原子操作，但会阻塞目标 key 的其他写入；若合并频繁，可考虑在应用层做轻量聚合（比如用布隆过滤器预筛 + HLL 最终兜底）。
典型结构示例：
-
hll:uv:20261020→ 全站日 UV -
hll:uv:20261020:page:home→ 首页日 UV -
hll:uv:20261020:channel:wechat→ 微信渠道日 UV
合并命令：PFMERGE hll:uv:20261020:all hll:uv:20261020:page:home hll:uv:20261020:channel:wechat
真正容易被忽略的是误差叠加：多个 PFMERGE 后再 PFCOUNT，误差不是简单相加，而是按统计学公式放大。如果业务对误差敏感（比如要精确比对环比增长百分点），得提前用离线样本校准偏移量，不能只依赖单次 PFCOUNT 返回值。
