1、redis在2.8.9版本添加了HyperLogLog结构;HyperLogLog是一种算法，并非redis独有. 2、redis HyperLogLog是用来做基数统计的算法，HyperLogLog的优点是：在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定的、并且使很小的。 3、在redis里面，每个HyperLogLog键只需要花费12kb内存，就可以计算接近2^64个不同元素的基数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。 4、目的是做基数统计，故不是集合，不会保存元数据，只记录数量而不是数值
什么是基数 比如数据集{1,3,5,7,5,7,8}，那么这个数据集的基数集为{1,3,5,7,8} ,基数(不重复元素)为5个.基数估计就是在误差可接受的范围内，快速计算基数。
例如：网页的 UV （一个人访问一个网站多次，但是还是算作一个人！） 传统的方式， set 保存用户的id，然后就可以统计 set 中的元素数量作为标准判断 ! 这个方式如果保存大量的用户id，就会比较麻烦！我们的目的是为了计数，而不是保存用户id。
详细说明：
一个非常简单的方案：你也许已经想到了一个简单的方案，那就是为每一个页面一个独立的 set 集合来存储所有当天访问过此页面的用户 ID。当一个请求过来时，我们使用 sadd 将用户 ID 塞进去就可以了。通过 scard 可以取出这个集合的大小，这个数字就是这个页面的 UV 数据。
但是，如果你的页面访问量非常大，比如一个爆款页面几千万的 UV，你需要一个很大的 set 集合来统计，这就非常浪费空间。如果这样的页面很多，那所需要的存储空间是惊人的。为这样一个去重功能就耗费这样多的存储空间，值得么？其实老板需要的数据又不需要太精确，105w 和 106w 这两个数字对于老板们来说并没有多大区别，So，有没有更好的解决方案呢？
Redis 提供了 HyperLogLog 数据结构就是用来解决这种统计问题的。HyperLogLog 提供不精确的去重计数方案，虽然不精确但是也不是非常不精确，标准误差是 0.81%，这样的精确度已经可以满足上面的 UV 统计需求了。
上面铺垫了这么，其实主要的命令有三个。
1.命令名称：pfadd功能： 将任意数量的元素添加到指定的HyperLogLog里面。 作为这个命令的副作用，HyperLogLog内部可能会被更新，以便反映一个不同的唯一元素估计数量（也即是集合的基数）。返回值： 整数回复：如果HyperLogLog的内部储存被修改了，那么返回1，否则返回0.
2.命令名称：pfcount功能： 当pfcount命令作用于单个键时，返回储存在给定键的HyperLogLog的近似基数，如果键不存在，那么返回0。 当pfcount命令作用于多个键时，返回所有给定HyperLogLog的并集的近似基数，这个近似基数是通过将所有给定HyperLogLog合并至一个临时HyperLogLog来计算得出的。返回值： 整数回复：给定HyperLogLog包含的唯一元素的近似数量。
3.命令名称：pfmerge功能： 将多个HyperLogLog合并（merge）为一个HyperLogLog，合并后的HyperLogLog的基数接近于所有输入HyperLogLog的可见集合(observed set)的并集。返回值： 返回OK
127.0.0.1:6379> PFadd mykey a b c d e f g h i j # 创建第一组元素 mykey 127.0.0.1:6379> PFCOUNT mykey # 统计 mykey 元素的基数数量 127.0.0.1:6379> PFadd mykey2 i j z x c v b n m # 创建第二组元素 mykey2 127.0.0.1:6379> PFCOUNT mykey2 127.0.0.1:6379> PFMERGE mykey3 mykey mykey2 # 合并两组 mykey mykey2 => mykey3 并集 127.0.0.1:6379> PFCOUNT mykey3 # 看并集的数量！
基数不大，数据量不大就用不上，会有点大材小用浪费空间；hyperloglog局限性就是只能统计基数数量，而没办法去知道具体的内容是什么；和bitmap相比，属于两种特定统计情况。
简单来说，HyperLogLog 去重比 bitmap 方便很多，一般可以bitmap和hyperloglog配合使用，bitmap标识哪些用户活跃hyperloglog计数。 一般使用：
统计注册 IP 数 统计每日访问 IP 数 统计页面实时 UV 数 统计在线用户数 统计用户每天搜索不同词条的个数
