直接换pfadd+pfcount可解决亿级uv内存爆炸问题，因hyperloglog仅需12kb，而set存1亿用户约需2gb；但需权衡语义变更、0.81%误差、不支持smembers及交集等限制。
直接换 PFADD + PFCOUNT 就能解决内存爆炸问题，但不能无脑替换——语义、精度、能力都变了，得按场景调整。
为什么 Set 在亿级 UV 下会内存溢出
Set 存的是原始值：每个用户 ID（比如 "uid:123456789"）占 16–25 字节，1 亿用户就是约 1.6GB。Redis 内存不是只存数据，还要维护哈希表结构、扩容冗余、RDB/AOF 开销，实际可能突破 2GB/键。而 HyperLogLog 固定只用 12 KB，不管你是 100 万还是 10 亿个元素。
这不是“省一点”，是差三个数量级。你查 INFO memory 时看到的 used_memory_human 突然不涨了，就是因为这个。
PFADD 插入后 PFCOUNT 始终为 0？先排查这三类问题
现象不是“没生效”，而是根本没成功初始化或被覆盖。常见原因：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 客户端传了
null或空字符串：Jedis 3.x 会静默丢弃，Lettuce 则可能抛异常；用redis-cli手动试PFADD test "a"看返回是否为(integer) 1 - 同名 key 被其他逻辑写成别的类型：比如误执行了
SET visitors:20260528 "init"，再PFADD就报WRONGTYPE Operation against a key holding the wrong kind of value - 管道（pipeline）里混用
DEL和PFADD：旧版 Redis 在 pipeline 中若 key 被删，PFADD可能返回0且不报错，建议拆开或加EXISTS判断
从 SADD 迁移到 PFADD 的兼容性断点
这不是语法替换，是统计模型切换。必须确认业务是否接受以下变化：
-
SMEMBERS不可用：HyperLogLog 不存原始值，无法反查有哪些用户；如果下游要导出“今日活跃用户列表”，不能迁 - 误差率
0.81%：1 亿 UV 实际值在 99,190,000–100,810,000 之间；判断“是否破千万”得预留误差空间，比如改成 ≥ 9,920,000 -
PFMERGE只支持并集：想算“连续两天登录用户”（交集），没法直接做；得回退到两个 Set +SINTERCARD，或者用布隆过滤器组合 - 小数据量反而更费内存：1000 个用户，Set 可能只占几百字节，
12 KB的 HyperLogLog 就显得浪费
什么时候该坚持用 Set，而不是硬套 HyperLogLog
别为了“省内存”牺牲可维护性。以下情况继续用 SADD/SCARD 更稳妥：
- 日活长期低于 10 万，内存压力根本不明显
- 需要精确去重后做后续操作，比如发券防重领、黑名单校验——
PFADD不保证内容比对，只看哈希结果 - 元素本身是长 URL 或 JSON 字符串：哈希计算开销上升，高频写入时 CPU 使用率比短 key 明显高
- 业务强依赖交集、差集逻辑，又不愿引入额外组件（如布隆过滤器）
真正省空间的前提，是你只要“大概有多少个”，而且这个“大概”业务上真能兜住。否则宁可多花几 MB，别为省内存把逻辑搞复杂。
