Redis HyperLogLog用12KB内存即可估算千万级UV，误差仅±0.81%，核心是PFADD添加、PFCOUNT查询、按日/业务建键，适用于运营报表等允许近似精度的场景。
用Redis HyperLogLog统计千万级UV，核心就三点：选对命令、建好键名、理解返回值。它不存原始ID，只做概率估算，所以12KB内存能扛住2⁶⁴量级数据，误差稳定在±0.81%，对运营报表、大促看板这类场景完全够用。
PFADD添加用户，关键看返回值不是“成功”，而是“是否新增
每次用户访问页面，执行：
PFADD uv:page:home:20260526 user_12345注意：返回1表示这个user_12345是今天第一次被识别（哪怕之前加过999次，这次是新桶值也会返回1）；返回0说明该用户已“被记住”，不会重复计数。别把它当操作成败判断——网络失败或语法错误会直接报错，不是返回0。
建议：
• 单次最多传1024个用户ID，超了必须拆条命令• 用户标识必须业务唯一且长期稳定，优先用user_id或device_id，不用session_id或临时token• 空字符串""、数字123、JSON串都合法，但业务上得能代表同一个自然人按天分key + 按业务域隔离，避免误去重一个HyperLogLog结构固定占12KB，不管里面是1个还是1亿个用户。所以不能复用一个key长期累加，而要按日期+业务维度建key：Redis 8.2.3 Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
下载推荐：uv:page:product:20260526（商品页，当天）
推荐：uv:channel:wechat:20260526（微信渠道，当天）
禁止：把App端user_id和PC端user_id混进同一个uv:20260526（跨端同ID会被当成1人）
禁止：用uv:total长期累计（内存不涨，但历史数据无法下线，key永久存在）
PFCOUNT查总数，多key合并是实时并集，不是简单相加
查单日UV：
PFCOUNT uv:page:home:20260526
查周UV（合并7天）：
PFCOUNT uv:page:home:20260520 uv:page:home:20260521 ... uv:page:home:20260526这等价于内存中临时PFMERGE再估算，结果是7天的去重并集。如果某用户连续7天都来，也只算1次。
注意：
• 多key PFCOUNT是纯读操作，不改源key，安全• 但高并发下频繁调用可能引发CPU尖峰，报表类任务建议避开流量高峰• 日常监控用单key查，汇总分析才用多key合并它不能回溯、不能精确去重，但特别适合“总量快、合并易”场景HyperLogLog天生不存原始数据，所以：• 无法查“今天UV里哪些人来自iOS”——需要配合Bitmap或落库日志• 无法知道具体漏了谁、多了谁——它只保证整体误差≤0.81%• 不能替代Set做登录态校验或权限判断
但它真正厉害的地方在于：
• 单实例Redis（4核8G）pipeline下PFADD QPS轻松破5万• 所有key共享同一套哈希逻辑，天然支持分布式合并• 比如分机房写入uv:sh:20260526、uv:bj:20260526，中心节点用PFMERGE一把合并