简介
Redis 在 2.8.9 版本添加了 HyperLogLog 结构
HyperLogLog 是用来做基数统计的算法，即对集合去重元素的计数
在输入元素的数量不超过2^64个，计算基数所需的内存最多12KB，该结构使用一种近似值算法，标准误差0.81%。
计算基数的方法分析
使用一般集合计算
随着统计元素的增加，内存消耗也剧增，资源消耗严重，不适合大数据量统计
bitmap
用位数组来表示各元素是否出现，每个元素对应一位，所需的总内存为n bit。能大大减少内存占用且位操作迅速。
如果要统计1亿个数据的基数值，大约需要内存100000000/8/1024/1024 ≈ 12M，内存减少占用的效果显著。然而统计一个对象的基数值需要12M，如果统计10000个对象，就需要将近120G，同样不能广泛用于大数据场景
但是这个方法是精确计算
概率算法
目前用于基数计数的概率算法包括:
- Linear Counting(LC)：早期的基数估计算法，LC在空间复杂度方面并不算优秀，实际上LC的空间复杂度与上文中简单bitmap方法是一样的（但是有个常数项级别的降低），都是O(Nmax)
- LogLog Counting(LLC)：LogLog Counting相比于LC更加节省内存，空间复杂度只有O(log2(log2(Nmax)))
- HyperLogLog Counting(HLL)：HyperLogLog Counting是基于LLC的优化和改进，在同样空间复杂度情况下，能够比LLC的基数估计误差更小
算法白话说明
通俗点说明： 假设我们为一个数据集合生成一个8位的哈希串，那么我们得到00000111的概率是很低的，也就是说，我们生成大量连续的0的概率是很低的。生成连续5个0的概率是1/32，那么我们得到这个串时，可以估算，这个数据集的基数是32
应用场景
适用场景特点
- 非精确统计，HyperLogLog是近似值算法，有0.81%标准误差
- 数据量巨大，不大就用不上，大材小用，浪费空间
- 只能统计集合基数（去重）数量，而没办法去知道具体的内容，自然也没办法返回集合元素
应用场景举例
- 统计 IP 数
- 统计 UV 数
- 统计用户每天搜索不同词条个数
命令说明
pfadd
PFADD key element [element ...]
时间复杂度: O(1) to add every element
功能说明: 添加元素到计算空间
返回值
- 如果同时指定了key和element，那么如果执行命令后HyperLogLog的近视基数发生了变化，则返回1，否则返回0
- 如果只指定了key，那么如果Key存在，返回0，否则创建key，返回1
示例: PFADD hll a b c d e f g
PFCOUNT
PFCOUNT key [key ...]
时间复杂度
- 使用单个键调用时，O（1）的平均恒定时间非常短。
- 使用多个键时，O（N）N是键的数目，并且在使用多个键调用时，常数时间要大得多
功能说明: 计算传入的所有key对应的元素集合去重基数
返回值: 基数计数近似值（标准误差约0.81%）
示例: pfcount hll hll2
特别说明
作为调用此函数的副作用，HyperLogLog可能会被修改，因为后8个字节编码用于缓存目的的最新计算基数。因此从技术上讲PFCOUNT是写命令
当用单个键调用PFCOUNT时，性能也很出色，PFCOUNT使用缓存来记住先前计算的基数，这种变化很少改变，因为大多数PFADD操作不会更新任何寄存器
当PFCOUNT调用多个key时，HyperLogLogs需要合并计算，这是缓慢的，而且合并的基数不能被缓存，所以有多个key使用时PFCOUNT可能需要的时间在一个毫秒级的数量级，不应滥用
PFMERGE
PFMERGE destkey sourcekey [sourcekey ...]
时间复杂度: O（N）合并N个HyperLogLogs，但是具有恒定的时间
功能说明: 将sourcekey 合并到 destkey, 如果destkey不存在，则新创建一个空的HyperLogLog，如果destkey存在，则将其视为sourcekey之一
返回值: 只返回ok
示例: PFMERGE hll3 hll1 hll2
