Redis学习(三)--位图、hyperloglog、布隆过滤器

---

前言

前面两篇文章
Redis学习(一)
Redis学习(二)–分布式锁、延时队列

---

一、位图

在我们平时开发过程中，会有一些 bool 型数据需要存取，比如用户一年的签到记录，签了是 1，没签是 0，要记录 365 天。如果使用普通的 key/value，每个用户要记录 365 个，当用户上亿的时候，需要的存储空间是惊人的。为了解决这个问题，Redis 提供了位图数据结构，这样每天的签到记录只占据一个位，365 天就是 365 个位，46 个字节 (一个稍长一点的字符串) 就可以完全容纳下，这就大大节约了存储空间。
位图不是特殊的数据结构，它的内容其实就是普通的字符串，也就是 byte 数组。我们可以使用普通的 get/set 直接获取和设置整个位图的内容，也可以使用位图操作 getbit/setbit 等将 byte 数组看成「位数组」来处理。

1.基本使用

Redis 的位数组是自动扩展，如果设置了某个偏移位置超出了现有的内容范围，就会自动将位数组进行零扩充。
接下来我们使用位操作将字符串设置为 hello (不是直接使用 set 指令)，首先我们需要得到 hello 的 ASCII 码，用 Python 命令行可以很方便地得到每个字符的 ASCII 码的二进制值。

>>> bin(ord('h')) 
'0b1101000' # 高位 -> 低位
>>> bin(ord('e')) 
'0b1100101'
>>> bin(ord('l')) 
'0b1101100'
>>> bin(ord('l')) 
'0b1101100'
>>> bin(ord('o')) 
'0b1101111'

如果使用 redis-cli 设置第一个字符，也就是位数组的前 8 位，我们只需要设置值为 1 的位，如上图所示，h 字符只有 1/2/4 位需要设置，e 字符只有 9/10/13/15 位需要设置。值得注意的是位数组的顺序和字符的位顺序是相反的。

127.0.0.1:6379> setbit s 1 1 
(integer) 0 
127.0.0.1:6379> setbit s 2 1 
(integer) 0 
127.0.0.1:6379> setbit s 4 1 
(integer) 0 
127.0.0.1:6379> setbit s 9 1 
(integer) 0 
127.0.0.1:6379> setbit s 10 1 
(integer) 0 
127.0.0.1:6379> setbit s 13 1 
(integer) 0 
127.0.0.1:6379> setbit s 15 1
(integer) 0 
127.0.0.1:6379> get s 
"he"

上面这个例子可以理解为「零存整取」，同样我们还也可以「零存零取」，「整存零取」。「零存」就是使用 setbit 对位值进行逐个设置，「整存」就是使用字符串一次性填充所有位数组，覆盖掉旧值。
零存零取

127.0.0.1:6379> setbit w 1 1 
(integer) 0 
127.0.0.1:6379> setbit w 2 1 
(integer) 0 
127.0.0.1:6379> setbit w 4 1 
(integer) 0 
127.0.0.1:6379> getbit w 1 # 获取某个具体位置的值 0/1
(integer) 1 
127.0.0.1:6379> getbit w 2 
(integer) 1 
127.0.0.1:6379> getbit w 4 
(integer) 1 
127.0.0.1:6379> getbit w 5 
(integer) 0

整存零取

127.0.0.1:6379> set w h # 整存
(integer) 0 
127.0.0.1:6379> getbit w 1 
(integer) 1 
127.0.0.1:6379> getbit w 2 
(integer) 1 
127.0.0.1:6379> getbit w 4 
(integer) 1 
127.0.0.1:6379> getbit w 5 
(integer) 0

如果对应位的字节是不可打印字符，redis-cli 会显示该字符的 16 进制形式。

127.0.0.1:6379> setbit x 0 1 
(integer) 0
127.0.0.1:6379> setbit x 1 1 
(integer) 0 
127.0.0.1:6379> get x 
"\xc0"

2.统计和查找

Redis 提供了位图统计指令 bitcount 和位图查找指令 bitpos，bitcount 用来统计指定位置范围内 1 的个数，bitpos 用来查找指定范围内出现的第一个 0 或 1。
比如我们可以通过 bitcount 统计用户一共签到了多少天，通过 bitpos 指令查找用户从哪一天开始第一次签到。如果指定了范围参数 [start, end] ，就可以统计在某个时间范围内用户签到了多少天，用户自某天以后的哪天开始签到。
接下来我们简单试用一下 bitcount 指令和 bitpos 指令:

127.0.0.1:6379> set w hello 
OK 
127.0.0.1:6379> bitcount w 
(integer) 21 
127.0.0.1:6379> bitcount w 0 0 # 第一个字符中 1 的位数
(integer) 3 
127.0.0.1:6379> bitcount w 0 1 # 前两个字符中 1 的位数
(integer) 7 
127.0.0.1:6379> bitpos w 0 # 第一个 0 位 (integer) 0 
127.0.0.1:6379> bitpos w 1 # 第一个 1 位 (integer) 1 
127.0.0.1:6379> bitpos w 1 1 1 # 从第二个字符算起，第一个 1 位 (integer) 9 
127.0.0.1:6379> bitpos w 1 2 2 # 从第三个字符算起，第一个 1 位 (integer) 17

魔术指令 bitfield
前文我们设置 (setbit) 和获取 (getbit) 指定位的值都是单个位的，如果要一次操作多个位，就必须使用管道来处理。不过 Redis 的 3.2 版本以后新增了一个功能强大的指令，有了这条指令，不用管道也可以一次进行多个位的操作。
bitfield 有三个子指令，分别是 get/set/incrby，它们都可以对指定位片段进行读写，但是最多只能处理 64 个连续的位，如果超过 64 位，就得使用多个子指令，bitfield 可以一次执行多个子指令。

接下来我们对照着上面的图看个简单的例子:

127.0.0.1:6379> set w hello 
OK 
127.0.0.1:6379> bitfield w get u4 0 # 从第一个位开始取 4 个位，结果是无符号数 (u)
(integer) 6 
127.0.0.1:6379> bitfield w get u3 2 # 从第三个位开始取 3 个位，结果是无符号数 (u)
(integer) 5 
127.0.0.1:6379> bitfield w get i4 0 # 从第一个位开始取 4 个位，结果是有符号数 (i)
1) (integer) 6 
127.0.0.1:6379> bitfield w get i3 2 # 从第三个位开始取 3 个位，结果是有符号数 (i)
1) (integer) -3

所谓有符号数是指获取的位数组中第一个位是符号位，剩下的才是值。如果第一位是 1，那就是负数。无符号数表示非负数，没有符号位，获取的位数组全部都是值。有符号数最多可以获取 64 位，无符号数只能获取 63 位 (因为 Redis 协议中的 integer 是有符号数，最大 64 位，不能传递 64 位无符号值)。如果超出位数限制，Redis 就会告诉你参数错误。
接下来我们一次执行多个子指令:

127.0.0.1:6379> bitfield w get u4 0 get u3 2 get i4 0 get i3 2 
1) (integer) 6 
2) (integer) 5 
3) (integer) 6 
4) (integer) -3

第三个子指令 incrby，它用来对指定范围的位进行自增操作。既然提到自增，就有可能出现溢出。如果增加了正数，会出现上溢，如果增加的是负数，就会出现下溢出。Redis 默认的处理是折返。如果出现了溢出，就将溢出的符号位丢掉。如果是 8 位无符号数 255，加 1 后就会溢出，会全部变零。如果是 8 位有符号数 127，加 1 后就会溢出变成 -128。
接下来我们实践一下这个子指令 incrby :

127.0.0.1:6379> set w hello 
OK 
127.0.0.1:6379> bitfield w incrby u4 2 1 # 从第三个位开始，对接下来的 4 位无符号数 +1
1) (integer) 11 
127.0.0.1:6379> bitfield w incrby u4 2 1 
1) (integer) 12 
127.0.0.1:6379> bitfield w incrby u4 2 1 
1) (integer) 13 
127.0.0.1:6379> bitfield w incrby u4 2 1 
1) (integer) 14 
127.0.0.1:6379> bitfield w incrby u4 2 1
1) (integer) 15 
127.0.0.1:6379> bitfield w incrby u4 2 1 # 溢出折返了
1) (integer) 0

bitfield 指令提供了溢出策略子指令 overflow，用户可以选择溢出行为，默认是折返 (wrap)，还可以选择失败 (fail) 报错不执行，以及饱和截断 (sat)，超过了范围就停留在最大最小值。overflow 指令只影响接下来的第一条指令，这条指令执行完后溢出策略会变成默认值折返 (wrap)。

二、HyperLoglog

Redis 提供了 HyperLogLog 数据结构就是用来解决一些统计问题的。HyperLogLog 提供不精确的去重计数方案，虽然不精确但是也不是非常不精确，标准误差是 0.81%。

1.使用方法

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

代码如下（示例）：

127.0.0.1:6379> pfadd codehole user1 
(integer) 1 
127.0.0.1:6379> pfcount codehole 
(integer) 1 
127.0.0.1:6379> pfadd codehole user2 
(integer) 1 
127.0.0.1:6379> pfcount codehole 
(integer) 2 
127.0.0.1:6379> pfadd codehole user3 
(integer) 1 
127.0.0.1:6379> pfcount codehole 
(integer) 3 
127.0.0.1:6379> pfadd codehole user4 
(integer) 1 
127.0.0.1:6379> pfcount codehole 
(integer) 4 
127.0.0.1:6379> pfadd codehole user5 
(integer) 1 
127.0.0.1:6379> pfcount codehole 
(integer) 5 
127.0.0.1:6379> pfadd codehole user6 
(integer) 1 
127.0.0.1:6379> pfcount codehole 
(integer) 6 
127.0.0.1:6379> pfadd codehole user7 user8 user9 user10 
(integer) 1 
127.0.0.1:6379> pfcount codehole 
(integer) 10

简单试了一下，发现还蛮精确的，一个没多也一个没少。接下来我们使用脚本，往里面灌更多的数据，看看它是否还可以继续精确下去，如果不能精确，差距有多大。我们看看Java代码的实现：

public class PfTest { 
    public static void main(String[] args) { 
        Jedis jedis = new Jedis(); 
        for (int i = 0; i < 1000; i++) { 
        jedis.pfadd("codehole", "user" + i); 
        long total = jedis.pfcount("codehole"); 
        if (total != i + 1) { 
            System.out.printf("%d %d\n", total, i + 1); 
            break; 
           } 
       } 
       jedis.close(); 
   } 
}

当然我们也可以用python

import redis 
client = redis.StrictRedis() 
for i in range(1000): 
    client.pfadd("codehole", "user%d" % i) 
    total = client.pfcount("codehole") 
    if total != i+1: 
        print total, i+1
        break

我们看看输出

> python pftest.py 
99 100

当我们加入第 100 个元素时，结果开始出现了不一致。接下来我们将数据增加到 10w 个，看看总量差距有多大。

import redis 
client = redis.StrictRedis() 
for i in range(100000): 
    client.pfadd("codehole", "user%d" % i) 
print 100000, client.pfcount("codehole")

输出

> python pftest.py 
100000 99723

差了 277 个，按百分比是 0.277%。

---

三、布隆过滤器

1.布隆过滤器是什么？

布隆过滤器可以理解为一个不怎么精确的 set 结构，当你使用它的 contains 方法判断某个对象是否存在时，它可能会误判。但是布隆过滤器也不是特别不精确，只要参数设置的合理，它的精确度可以控制的相对足够精确，只会有小小的误判概率。
当布隆过滤器说某个值存在时，这个值可能不存在；当它说不存在时，那就肯定不存在。打个比方，当它说不认识你时，肯定就不认识；当它说见过你时，可能根本就没见过面，不过因为你的脸跟它认识的人中某脸比较相似 (某些熟脸的系数组合)，所以误判以前见过你。
套在上面的使用场景中，布隆过滤器能准确过滤掉那些已经看过的内容，那些没有看过的新内容，它也会过滤掉极小一部分 (误判)，但是绝大多数新内容它都能准确识别。这样就可以完全保证推荐给用户的内容都是无重复的。
Redis 中的布隆过滤器
Redis 官方提供的布隆过滤器到了 Redis 4.0 提供了插件功能之后才正式登场。布隆过滤器作为一个插件加载到 Redis Server 中，给 Redis 提供了强大的布隆去重功能。
下面我们来体验一下 Redis 4.0 的布隆过滤器，为了省去繁琐安装过程，我们直接用 Docker 吧。

> docker pull redislabs/rebloom # 拉取镜像
> docker run -p6379:6379 redislabs/rebloom # 运行容器
> redis-cli # 连接容器中的 redis 服务

如果上面三条指令执行没有问题，下面就可以体验布隆过滤器了。

2.布隆过滤器的基本使用

布隆过滤器有二个基本指令， bf.add 添加元素， bf.exists 查询元素是否存在，它的用法和 set 集合的 sadd 和 sismember 差不多。注意 bf.add 只能一次添加一个元素，如果想要一次添加多个，就需要用到 bf.madd 指令。同样如果需要一次查询多个元素是否存在，就需要用到 bf.mexists 指令。

3.注意事项

布隆过滤器的 initial_size 估计的过大，会浪费存储空间，估计的过小，就会影响准确率，用户在使用之前一定要尽可能地精确估计好元素数量，还需要加上一定的冗余空间以避免实际元素可能会意外高出估计值很多。布隆过滤器的 error_rate 越小，需要的存储空间就越大，对于不需要过于精确的场合， error_rate 设置稍大一点也无伤大雅。比如在新闻去重上而言，误判率高一点只会让小部分文章不能让合适的人看到，文章的整体阅读量不会因为这点误判率就带来巨大的改变。

4.布隆过滤器的原理

每个布隆过滤器对应到 Redis 的数据结构里面就是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的 hash 值算得比较均匀。向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。再把位数组的这几个位置都置为 1 就完成了 add 操作。
向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出来，看看位数组中这几个位置是否都位 1，只要有一个位为 0，那么说明布隆过滤器中这个 key 不存在。如果都是 1，这并不能说明这个 key 就一定存在，只是极有可能存在，因为这些位被置为 1 可能是因为其它的 key 存在所致。如果这个位数组比较稀疏，这个概率就会很大，如果这个位数组比较拥挤，这个概率就会降低。具体的概率计算公式比较复杂，感兴趣可以阅读扩展阅读，非常烧脑，不建议读者细看。
使用时不要让实际元素远大于初始化大小，当实际元素开始超出初始化大小时，应该对布隆过滤器进行重建，重新分配一个 size 更大的过滤器，再将所有的历史元素批量 add 进去 (这就要求我们在其它的存储器中记录所有的历史元素)。因为 error_rate 不会因为数量超出就急剧增加，这就给我们重建过滤器提供了较为宽松的时间。

5.布隆过滤器的其它应用

在爬虫系统中，我们需要对 URL 进行去重，已经爬过的网页就可以不用爬了。但是 URL 太多了，几千万几个亿，如果用一个集合装下这些 URL 地址那是非常浪费空间的。这时候就可以考虑使用布隆过滤器。它可以大幅降低去重存储消耗，只不过也会使得爬虫系统错过少量的页面。
布隆过滤器在 NoSQL 数据库领域使用非常广泛，我们平时用到的 HBase、Cassandra 还有LevelDB、RocksDB 内部都有布隆过滤器结构，布隆过滤器可以显著降低数据库的 IO 请求数量。当用户来查询某个 row 时，可以先通过内存中的布隆过滤器过滤掉大量不存在的 row 请求，然后再去磁盘进行查询。
邮箱系统的垃圾邮件过滤功能也普遍用到了布隆过滤器，因为用了这个过滤器，所以平时也会遇到某些正常的邮件被放进了垃圾邮件目录中，这个就是误判所致，概率很低。