应使用pfadd而非set统计话题讨论人数，因前者基于hyperloglog以12kb内存实现百万级去重计数（误差0.81%），而set需80mb；pfadd不存原始数据、不可删除、无法回溯具体用户，仅适用于允许误差的热度估算场景。
为什么不用 SET 而要用 PFADD 统计话题讨论人数
因为“谁在聊这个话题”本质是去重计数问题，不是查用户列表。用 SET 存每个用户 ID，100 万活跃用户轻松吃掉 80MB 内存；而 HyperLogLog 只要 12KB，误差率稳定在 0.81%——对热点排行这类场景，少算几百人完全可接受。
- 话题粒度越细（比如按小时+话题名组合键），越适合
PFADD：如topic:ai:20260310_20 -
PFADD返回1表示基数可能更新，0不代表重复，只是当前哈希未影响估算值，不能用来做幂等判断 - 别拿
PFADD当日志用——它不存原始数据，后续无法回溯“张三到底聊没聊过 AI”
PFCOUNT 怎么避免统计口径错乱
直接 PFCOUNT topic:ai 看起来简单，但实际容易漏掉跨时段、跨子话题的聚合。比如“AI 编程”和“AI 设计”都属于 AI 大类，但单独统计会低估整体热度。
- 设计键名时就预留合并能力：用
topic:ai:programming、topic:ai:design，再定期PFMERGE topic:ai:all topic:ai:programming topic:ai:design - 不要在高并发写入时频繁调
PFCOUNT——它本身是 O(1)，但若同时有大量PFADD，内部寄存器刷新可能短暂影响精度 - 如果需要“最近 1 小时内新参与人数”，得另起一个带 TTL 的 key：
EXPIRE topic:ai:hourly 3600，否则PFCOUNT返回的是全量历史估算值
误把 HyperLogLog 当成实时在线列表用的后果
有人看到“在线人数”四个字，就想用 PFADD + PFCOUNT 替代用户心跳机制——这是典型的数据结构误配。前者只回答“总共多少人来过”，后者要回答“此刻谁还在”。
-
PFADD不支持删除、不支持查成员、不支持按时间剔除，根本没法做“30 分钟无操作自动下线” - 真要追踪活跃状态，得用
Sorted Set存ZADD topic:ai:active <timestamp> user_id</timestamp>，再配合ZREMRANGEBYSCORE清理 - 如果硬要用
HyperLogLog模拟实时性，只能靠高频重建 key（如每分钟切一个新 key），但会丢失连续性，且无法归因到具体用户
生产环境里 PFADD 调用失败却不报错的坑
Redis 客户端默认不会因 PFADD 返回 0 就抛异常，但有些 SDK（比如早期 Jedis）在 pipeline 中遇到网络抖动时，会静默丢弃部分命令响应，导致你以为数据进了，其实没进。
- 关键业务必须校验返回值：
if (jedis.pfadd(key, userId) == 1) { /* 记录成功日志 */ } - 别在单个
PFADD后立刻PFCOUNT验证——由于 Redis 的 lazy-rehash 机制，刚插入后立即读可能略低于预期（尤其小数据量时误差更明显） - 上线前务必压测：用真实用户 ID 流模拟 10 万 QPS，观察
info memory中used_memory_overhead是否突增——异常增长往往意味着 key 膨胀或 pipeline 错误累积
真正难的不是怎么写那几行 PFADD，而是想清楚你要的答案到底是“历史上聊过的人”，还是“现在正敲键盘的人”。选错结构，后面所有优化都是在给错误擦屁股。
