Redis之HyperLogLog底层原理与使用场景

1：业务场景引入
HyperLogLog常用于大数据量的统计，比如页面访问量统计或者用户访问量统计。

①需求：要统计一个页面的访问量(PV)

①方案：直接用redis计数器或者直接存数据库都可以

②需求：要统计一个页面的用户访问量(UV)，即：一个用户一天内如果访问多次的话，也只能算一次

②方案：可能会想到用SET集合来做，因为SET集合是有去重功能的，key存储页面对应的关键字，value存储对应userId

③需求：假如有几千万访问量，为了统计一个访问量，要频繁创建SET集合对象。

③方案：针对大访问量需要进行统计的问题，redis实现了一种HyperLogLog算法。

2：HyperLogLog主要语法
Redis集成的HyperLogLog使用语法主要有pfadd和pfcount，顾名思义，一个是来添加数据，一个是来统计的，使用比较容易掌握，不过算法是比较复杂的。

HyperLogLog 这个数据结构的发明人 是Philippe Flajolet 教授，所以使用pf前缀。

 

pfadd添加
影响基数估值则返回1否则返回0.若key不存在则创建

时间复杂度O(1)

 

 pfcount获得基数值
得到基数值，白话就叫做去重值（1，1，2，2，3）的插入pfcount得到的是3

可一次统计多个key

时间复杂度为O(N)，N为key的个数

返回值是一个带有 0.81% 标准错误（standard error）的近似值.

 

 pfmerge合并多个key
取多个key的并集

命令只会返回 OK.

时间复杂度为O（N）

 

 3：应用场景
统计注册 IP 数

统计每日访问 IP 数

统计页面实时 UV 数

统计在线用户数

统计用户每天搜索不同词条的个数

说明：基数不大，数据量不大就用不上，会有点大材小用浪费空间

有局限性，就是只能统计基数数量，而没办法去知道具体的内容是什么

和bitmap相比，属于两种特定统计情况，简单来说，HyperLogLog 去重比 bitmap 方便很多

一般可以bitmap和hyperloglog配合使用，bitmap标识哪些用户活跃，hyperloglog计数

4：总结
1：HyperLogLog是一种算法，并非redis独有

2：目的是做基数统计，故不是集合，不会保存元数据，只记录数量而不是数值。

3：耗空间极小，支持输入非常体积的数据量

4：核心是基数估算算法，主要表现为计算时内存的使用和数据合并的处理。最终数值存在一定误差

5：redis中每个hyperloglog key占用了12K的内存用于标记基数

6：pfadd命令并不会一次性分配12k内存，而是随着基数的增加而逐渐增加内存分配；而pfmerge操作则会将sourcekey合并后存储在12k大小的key中，这由hyperloglog合并操作的原理（两个hyperloglog合并时需要单独比较每个桶的值）可以很容易理解。

7：误差说明：基数估计的结果是一个带有 0.81% 标准错误（standard error）的近似值。是可接受的范围

8：Redis 对 HyperLogLog 的存储进行了优化，在计数比较小时，它的存储空间采用稀疏矩阵存储，空间占用很小，仅仅在计数慢慢变大，稀疏矩阵占用空间渐渐超过了阈值时才会一次性转变成稠密矩阵，才会占用 12k 的空间

9：HyperLogLog算法一开始就是为了大数据量的统计而发明的，所以很适合那种数据量很大，然后又没要求不能有一点误差的计算，HyperLogLog 提供不精确的去重计数方案，虽然不精确但是也不是非常不精确，标准误差是 0.81%，不过这对于页面用户访问量是没影响的，因为这种统计可能是访问量非常巨大，但是又没必要做到绝对准确，访问量对准确率要求没那么高，但是性能存储方面要求就比较高了，而HyperLogLog正好符合这种要求，不会占用太多存储空间，同时性能不错。

5：JAVA代码源码测试