redis hyperloglog用12kb内存估算uv，误差±0.81%，但需用户标识归一化、按天分key隔离，并理解pfadd返回值表示新元素识别而非操作成败，pfcount为实时并集估算。
Redis 的 HLL 确实能用约 12 KB 内存估算上亿级 UV，但直接 PFADD 就跑起来，大概率会漏数或不准——关键在用户标识的归一化和时间窗口的隔离。
为什么 PFADD 单次调用不等于一次有效 UV 计数
HyperLogLog 本质是概率算法，不存原始值，只靠哈希指纹去重。如果传入的用户标识没做清洗，比如：
-
"user123"和"USER123"被当成两个独立 ID - 带时间戳或随机参数的 URL（如
/home?ts=1715823400）导致同一用户多次触发PFADD - 未登录用户用
localStorage生成的 client_id 在跨设备/清除缓存后失效，重复计为新用户
这些都会让 HLL 的误差从理论上的 ±0.81% 滑向不可控。真正要压低误差，得在写入前统一做小写、截断、剔除 query 参数等处理，而不是依赖 Redis 自身。
按天统计 UV 必须用独立 key，不能复用同一个 key
很多人图省事，把所有请求都往一个 key（比如 uv:total）里塞，结果发现“今日 UV”永远等于“历史累计 UV”。PFADD 是累加式操作，没有自动过期或分时切片能力。
正确做法是按日期生成 key，例如：
PFADD uv:20240515 user_abc PFADD uv:20240515 user_def PFADD uv:20240516 user_abc // 同一用户跨天重复计入
再配合 EXPIRE uv:20240515 86400（虽然 HLL 本身不支持 TTL，但 key 可设），或由业务层定期清理旧 key。注意：不要用 PEXPIREAT 给 HLL key 设毫秒级过期——部分 Redis 版本对 HLL 类型的过期支持不稳定。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
PFCOUNT 返回的是估算值，别当精确数字用
PFCOUNT 的结果是基于 HyperLogLog 内部寄存器计算出的近似值，不是真实基数。它可能比实际少 5%，也可能多 3%，尤其在数据量
如果你需要“今天至少有多少 UV”，可以考虑：
- 用
PFADD+PFCOUNT做趋势监控（日环比、小时峰值） - 对核心活动页，额外用布隆过滤器或小型 Set 缓存最近 1 小时的 ID，做二次校验
- 绝对不允许把
PFCOUNT结果直接展示在财务或 KPI 报表中
另外，PFCOUNT 是 O(1) 时间复杂度，但并发高时仍可能成为瓶颈——多个客户端同时读同一个 HLL key，Redis 会串行执行内部合并逻辑，建议加本地缓存（比如 5 分钟 TTL）。
合并多日 UV 不能简单加总，要用 PFMERGE
想算“过去 7 天 UV”，不是 PFCOUNT uv:20240510 + … + PFCOUNT uv:20240516。那样得到的是每日 UV 之和，完全没去重。
必须先合并再统计：
PFMERGE uv:7days uv:20240510 uv:20240511 ... uv:20240516 PFCOUNT uv:7days
注意：PFMERGE 会新建或覆盖目标 key，且源 key 必须都是 HLL 类型。如果某天没流量、key 不存在，PFMERGE 会静默跳过——这没问题；但如果误把普通 string key 当作 HLL 加进去，命令直接报错 WRONGTYPE Key is not a valid HyperLogLog string value。
最常被忽略的一点：HLL 的内存占用和 key 名长度无关，但和插入的唯一元素数量无关——它始终固定约 12 KB（Redis 用 16384 个 6-bit 寄存器）。所以别为了“省内存”而手动分桶（比如按首字母拆成 uv:a, uv:b），那只会让合并和维护变得更脆弱。
