Redis HyperLogLog数据结构

思考一个常见的业务问题：如果你负责开发维护一个大型的网站，有一天老板找产品经理要网站上每个网页每天的UV数据，然后让你来开发这个统计模块，你会如何实现。

你也许已经想到了一个简单的方案，那就是为每一个页面设置一个独立的set集合来存储所有当天访问过此页面的用户ID。当一个请求过来时，我们使用sadd将用户ID塞进去就可以了。通过scard可以取出这个集合的大小，这个数字就是这个页面的UV数据。没错，这个一个非常简单的可行方案。

但是，如果你的页面访问量非常大，比如一个爆款页面可能有几千万个UV，你就需要一个很大的set集合来统计，这就非常浪费空间。如果这样的页面很多，那所需要的存储空间是惊人的。为这样一个去重功能就耗费这么多的存储空间，值得吗？其实老板所需要的数据并不需要太精确，105万和106万这两个数字对于老板来说并没有多大区别。那么，有没有更好的解决方案呢？

Redis提供的HyperLogLog数据结构就是用来解决这种统计问题的。HyperLogLog提供不精确的去重计数方案，虽然不精确，但是也不是非常离谱，标准误差是0.81%，这样的精确度已经可以满足上面的UV统计需求了。

1、使用方法

HyperLogLog提供了两个指令pfadd和pfcount，根据字面意思很好理解，一个是增加计数，一个是获取计数。pfadd和set集合的sadd的用法是一样的，来一个用户ID，就将用户ID塞进去就是。pfcount和scard的用法是一样的，直接获取计数值。

2、pfmerge适合的场合

HyperLogLog除了提供上面的pfadd和pfcount之外，还提供了第三个指令pfmerge，用于将多个pf计数值累加在一起形成一个新的pf值。

比如在网站中我们有两个内容差不多的页面，运营说需要对这两个页面的数据进行合并，其中页面的UV访问量也需要合并，那这个时候pfmerge就可以派上用场了。

3、注意事项

HyperLogLog这个数据结构不是免费的。这倒不是说使用这个数据结构要花钱，而是因为它需要占据12KB的存储空间，所以不适合统计单个用户相关的数据。如果你的用户有上亿个，可以算算，这个空间成本是非常惊人的。但是相比set存储方案，HyperLogLog所使用的空间那就只能算九牛一毛了。

不过你额不必过于担心，因为Redis对HyperLogLog的存储进行了优化，在计数比较小时，它的存储空间采用稀疏矩阵存储，空间占用很小，仅仅在计数慢慢变大、稀疏矩阵占用空间渐渐超过了阀值时，才会一次性转变成稠密矩阵，才会占用12KB的空间。