Redis HyperLogLog类型应用场景

HyperLogLog是用来做基数统计的，优点是在只需要统计元素总数的场景下，每个key只需要12KB，就可以计算接近 2^64 个不同元素的基数。区别于bitmap 和 set随着存储元素的增多，占用内存也会增加 有着巨大优势。

HyperLogLog类型的常用操作

PFADD 添加统计元素

可以看到元素是可以为任意字符串(这有区别于Bitmap只能存数字)

127.0.0.1:6379> PFADD pf a # a元素存入pf 基数统计
(integer) 1
127.0.0.1:6379> PFADD pf b
(integer) 1
127.0.0.1:6379> PFADD pf c
(integer) 1
127.0.0.1:6379> PFADD pf d
(integer) 1

---

PFCOUNT 统计基数个数

127.0.0.1:6379> PFCOUNT pf
(integer) 4

---

PFMERGE 将多个统计基数合并

127.0.0.1:6379> PFADD pf2 1 2 3 4 5 6 # 新增一个基数统计
(integer) 1
127.0.0.1:6379> PFCOUNT pf2
(integer) 6

127.0.0.1:6379> PFMERGE pfmerge pf pf2 # 合并
OK
127.0.0.1:6379> PFCOUNT pfmerge # 计算合并后的总数
(integer) 10

需要注意的是，HyperLogLog 的统计规则是基于概率，所以统计结果有一定误差的，标准误算率是 0.81%。

---

实际应用场景

1.UV统计

之前我们使用Set类型统计了UV, 但是如果我们有很多页面需要统计UV，并且我们不需要很精确的值时，使用set会占用很多内存空间，这时就可以使用HyperLogLog类型。

127.0.0.1:6379> PFADD day:app:20240526 u1 # 用户ID:u1记录
(integer) 1
127.0.0.1:6379> PFADD day:app:20240526 u2
(integer) 1
127.0.0.1:6379> PFADD day:app:20240526 u3
(integer) 1
127.0.0.1:6379> PFADD day:app:20240526 u4
(integer) 1
127.0.0.1:6379> PFCOUNT day:app:20240526 # 统计5月26号的app uv
(integer) 4

也可以先统计 每个页面的UV, 再汇总成为整个站点的整体UV

127.0.0.1:6379> PFADD day:page1:20240526 u1 u2 u4 
(integer) 1
127.0.0.1:6379> PFCOUNT day:page1:20240526 # page1 uv
(integer) 3

127.0.0.1:6379> PFADD day:page2:20240526 u1 u4
(integer) 1
127.0.0.1:6379> PFCOUNT day:page2:20240526 # page2 uv
(integer) 2

127.0.0.1:6379> PFADD day:page3:20240526 u3 u4
(integer) 1
127.0.0.1:6379> PFCOUNT day:page3:20240526 # page3 uv
(integer) 2

127.0.0.1:6379> PFMERGE day:app:20240526 day:page1:20240526 day:page2:20240526 day:page3:20240526 # 合并所有页面的uv
OK
127.0.0.1:6379> PFCOUNT day:app:20240526 # 整个站点uv
(integer) 4