PFADD 支持一次添加多个用户ID并自动去重，非逐个累加；PFCOUNT为概率估算，误差率约0.81%，不适用于强一致性场景；key需设TTL防内存泄漏；HyperLogLog内存仅为SET的1/20000，但不支持精确查询与集合运算。
PFADD 一次只能加一个用户 ID 吗？
不是。虽然 PFADD 命令语法支持多个参数，但实际效果是「一次性去重后计数」，不是逐个累加。比如 PFADD page:home:user:uv user1 user2 user1，重复的 user1 会被忽略，最终只算 2 个独立用户。
- 每次调用
PFADD都会触发内部稀疏寄存器更新，频繁单条写入（如每个 PV 都发一次命令）比批量合并后写入开销更大 - 如果业务能聚合用户行为（例如 N 秒内同一页面的多次访问只记首次），建议先在应用层 dedupe，再批量
PFADD - 注意：Redis 不保证
PFADD的原子性跨 key，不同页面 UV 必须用不同 key，不能共用一个PFADD调用混写
PFCOUNT 返回值突然跳变或不准怎么办？
PFCOUNT 是概率估算，标准误差率约 0.81%，对千万级 UV 来说误差可能达 ±8 万。它不是精确计数工具，跳变本身是正常现象——尤其当新用户集中涌入、触发内部寄存器重组时。
- 不要把
PFCOUNT结果用于财务、审计等强一致性场景 - 如果发现连续两次
PFCOUNT差值异常大（比如从 100 万突增至 150 万），大概率是底层 HyperLogLog 结构刚完成稀疏→稠密转换，属于设计使然，不是数据损坏 - 想验证估算是否合理？可用
DEBUG OBJECT查看 encoding 类型和 lru 字段变化，但生产环境慎用
页面 UV 按天分桶，key 怎么设计才不爆内存？
别用 page:home:uv:20240520 这种静态 key。UV 数据有天然生命周期，长期堆积未清理的 key 会持续占用内存，且无法利用 Redis 的过期策略自动释放。
- 必须给 key 设置 TTL，推荐用
EXPIRE配合业务周期，例如EXPIRE page:home:uv:20240520 86400（24 小时后过期） - 更稳妥的做法：用时间戳作为 key 后缀 + 定期脚本清理，避免依赖 Redis 自动过期（存在延迟或被禁用风险）
- 注意：
PFADD不会自动创建带过期的 key，TTL 必须显式设置；且EXPIRE对已存在的 key 才生效，首次PFADD后需立即补EXPIRE
HyperLogLog 和 SET 相比，省多少内存？
差别巨大。一个存 1000 万个用户 ID 的 SET，按平均 ID 长度 32 字节算，至少占 320MB；而同样规模的 HyperLogLog 只需约 12KB —— 内存压缩比超 2 万倍。
- 代价是：无法获取具体有哪些用户，也不能做交并差（
PFMERGE只支持合并，不支持取交集） - 如果业务后续要查「哪些用户同时访问了 A 和 B 页面」，HyperLogLog 就不合适，得切回
SET或布隆过滤器+日志回溯 - 另外，
PFADD时间复杂度是 O(1)，但常数略高；高频写入下，相比INCR或HINCRBY，仍属轻量级操作
实际部署时最容易被忽略的，是 key 生命周期管理和误差边界的接受程度——很多人测完 PFCOUNT 准确性就上线，结果两周后发现 UV 统计偏差越来越大，其实只是忘了每天清理旧 key 或没意识到这是估算值。
