在互联网业务中，独立访客数（UV）是衡量站点热度的基础指标。传统做法把每个用户的唯一标识写进Redis的Set结构，靠SCARD取基数。当用户量上涨到千万级别，单日UV就会占用几十兆内存，多日留存更是难以承受。Redis提供的HyperLogLog是一类专门做基数统计的概率数据结构，它不保存原始元素，只用极小的空间给出近似去重计数，非常适合UV场景。
HyperLogLog的底层原理与误差来源
HyperLogLog的核心思想来自伯努利试验。当一串随机二进制流出现连续k个0的概率约为1/2^k时，如果我们观察所有元素哈希后的比特串，并记录下「最长前导零个数」的最大值，就能反推总共见过多少个不同元素。Redis对每个元素的64位哈希值取低14位作为桶下标，分出16384个寄存器，每个寄存器只存该桶内最长前导零长度，因此总内存恒定在16384乘以6比特约等于12KB。
由于是概率估算，结果并不是绝对精确。Redis实现的HyperLogLog在标准条件下最大误差约0.81%，也就是说一百万UV可能偏差八千左右。对于大多数运营分析、流量大盘而言，这种精度完全可接受。要注意的是，HyperLogLog不会返回具体用户列表，它只回答「大概有多少人」，所以如果业务要求精确去重且后续要逐条处理用户，就不能用它替代Set。
在哈希函数的选择上，Redis使用自己内部的MurmurHash64A变体，能较好地把用户ID打散到均匀比特分布。这也意味着输入即便是自增数字或者带规律的字符串，经过哈希后依然能保持统计有效性。当多个HyperLogLog做合并时，只需按桶取最大值，因此PFMERGE的时间复杂度是O(n)且结果仍满足误差边界，这是它相比其他结构做跨天、跨渠道聚合的最大优势。
核心命令与基础代码实践
Redis为HyperLogLog提供了三条主要命令：PFADD用于添加元素，PFCOUNT用于获取估算基数，PFMERGE用于合并多个HyperLogLog。下面是一段Python中使用redis-py客户端记录某页面UV的示例，每天使用独立key，方便后续按日期统计。
import redis
client = redis.StrictRedis(host='127.0.0.1', port=6379, db=0)
def record_uv(page_id, user_id):
# 以日期和页面拼接key，如 uv:20240501:home
key = f"uv:20240501:{page_id}"
# PFADD返回1表示可能新增了基数，0表示已存在近似
return client.pfadd(key, user_id)
def get_uv(page_id):
key = f"uv:20240501:{page_id}"
# PFCOUNT返回近似独立用户数
return client.pfcount(key)
# 示例调用
record_uv("home", "user_1001")
record_uv("home", "user_1002")
print(get_uv("home"))
如果你在命令行直接操作，等价指令为：PFADD uv:20240501:home user_1001 与 PFCOUNT uv:20240501:home。由于HyperLogLog的key在Redis内部以稀疏或稠密两种编码存储，元素很少时占用更低，只有达到阈值才转成固定12KB，这对小流量页面也很友好。
当需要统计一周内某页面的UV而非每日相加时，可以使用PFMERGE把七天key合并成新key再PFCOUNT，这样得到的是去重后的周UV，而不是简单求和。示例如下：
PFMERGE uv:week:home uv:20240501:home uv:20240502:home uv:20240503:home uv:20240504:home uv:20240505:home uv:20240506:home uv:20240507:home PFCOUNT uv:week:home
与Set、Bitmap方案的对比及选型建议
我们常用来做去重的还有Set和Bitmap。Set用SADD加用户，SCARD取数，精确但内存随UV线性增长。假设每个用户ID平均占32字节，千万UV约320MB，集群中复制成本极高。Bitmap则用位图，每个用户映射到偏移量的一比特，一亿用户约12MB，但它要求用户有连续整数ID，且跨日合并要用BITOP OR，在稀疏ID下浪费严重。
下表给出三种结构在日活一千万场景下的直观比较：
| 方案 | 内存占用 | 是否精确 | 可否取用户列表 | 合并成本 |
|---|---|---|---|---|
| Set | 约300MB+ | 是 | 可以 | 高，需遍历 |
| Bitmap | 约1.2MB（理想ID空间） | 是 | 可反解偏移 | 中，BITOP |
| HyperLogLog | 约12KB | 否（误差0.81%） | 不可以 | 低，PFMERGE |
从表中可见，如果你的目标是看板、报警、趋势分析，HyperLogLog几乎总是最优解。但遇到需要给UV用户发券、做人群包等必须精确且可取列表的需求，应保留Set或结合布隆过滤器先做粗筛再落Set。实践中也有混合架构：用HyperLogLog做实时大屏，用Set按小时滚动保留近期明细，既控成本又留能力。
另外要注意HyperLogLog在Redis集群里和普通key一样分布到槽位，PFMERGE涉及多key时必须保证在同一槽或使用hash tag，否则会报CROSSSLOT错误。例如把key设计为{uv}:20240501:home形式，让大括号内容参与哈希，就能稳定落在同一节点，方便做多日合并脚本的自动化调度。
生产环境落地注意事项
在真实系统中，用户标识应使用稳定且唯一的ID，如登录态UID或设备指纹。如果直接拿IP做UV，会因NAT和运营商出口导致严重低估；若用带随机串的session则高估。建议在前端埋点网关处统一生成或补全用户标识，再调用PFADD，避免脏数据进入统计流。
监控方面，由于HyperLogLog的PFCOUNT本身极快，可配置定时任务把每日UV快照写入时序库，用于画曲线。同时留意Redis内存告警，虽然单个HyperLogLog很小，但业务线多、维度组合多（渠道×页面×版本）时key数量会膨胀，需要设置过期时间或定期聚合归档。可以利用PFMERGE生成月级key后删除日级key，既保留历史又可释放大量稀疏结构。
最后补充一个常见误区：有人试图用GET查看HyperLogLog的value，结果看到乱码便以为数据损坏。实际上其内部是专用编码，只能通过PF系列命令操作。也不要对HyperLogLog执行APPEND或INCR等普通字符串命令，那样会破坏结构使统计失效。只要遵循PFADD、PFCOUNT、PFMERGE三板斧，UV统计就能长期稳定且低成本运行。
RedisHyperLogLogUV统计修改时间：2026-08-15 19:48:18