《Redis深度历险》 读书笔记（2）

位图(Bitmap)

• 什么是位图？

  • 一串连续的二进制数字，每一位所在的位置为偏移量(offset)， 在位图上可执行AND, OR, XOR以及其他的位操作。
  • 位图实际上是一个byte数组，可以使用普通的get/set获取和设置整个位图的内容，也可以使用getbit/setbit 等将 byte 数组看成「位数组」来处理

• 使用场景

  • 例子：统计用户一年的签到记录。
    • 用普通的key/value需要记录365个，当用户数量达到上亿时，需要很大的存储空间。使用位图的话，每天签到的记录占据一个位，365天就是365个位，46个字节，可以大大节约存储空间
  • 例子：统计日活用户。
    • 建立一个bitmap，每一位标识一个用户ID，当某个用户访问时就将此用户的位置标识为1。即每次登录时会执行一次redis.setbit(daily_active_users, user_id, 1)的操作。时间复杂度为O(1)。
    • 扩展： 统计整个周或整个月的活跃用户，可以通过对范围内的所有bitmap求并集，得出新的bitmap，并对它计数。

• 如何计数？

  • 通过位图统计指令 bitcount 和位图查找指令 bitpos，bitcount 用来统计指定位置范围内 1 的个数，bitpos 用来查找指定范围内出现的第一个 0 或 1。
  • 需要注意的点：用bitpos指令时，如果指定了范围参数[start, end]， 那么要注意start和end是字节索引，也就是说指定的位范围必须是 8 的倍数，所以如果我们要计算某个月内用户签到了多少天，需要将这个月的字节内容全部取出来（用getrange)，然后在内存里统计，比较繁琐。

• 高级用法(bitfield)

  • 使用setbit和getbit来指定为的值时，只能指定一个位，如果要一次操作多个位，可以用bitfield来操作(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代表负数，0代表正数。获取的位数组全部都是值。有符号数最多可以获取 64 位，无符号数只能获取 63 位 (因为 Redis 协议中的 integer 是有符号数，最大 64 位，不能传递 64 位无符号值)。

    子指令 incrby，它用来对指定范围的位进行自增操作。如果出现了溢出，就将溢出的符号位丢掉。例如，如果是 8 位无符号数 255，加 1 后就会溢出，会全部变零。如果是 8 位有符号数 127，加 1 后就会溢出变成 -128。

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

  • 饱和截断 SAT

    127.0.0.1:6379> set w hello
    OK
    127.0.0.1:6379> bitfield w overflow sat incrby u4 2 1
    1) (integer) 11
    127.0.0.1:6379> bitfield w overflow sat incrby u4 2 1
    1) (integer) 12
    127.0.0.1:6379> bitfield w overflow sat incrby u4 2 1
    1) (integer) 13
    127.0.0.1:6379> bitfield w overflow sat incrby u4 2 1
    1) (integer) 14
    127.0.0.1:6379> bitfield w overflow sat incrby u4 2 1
    1) (integer) 15
    127.0.0.1:6379> bitfield w overflow sat incrby u4 2 1  # 保持最大值
    1) (integer) 15
    

  • 失败不执行 FAIL

    127.0.0.1:6379> set w hello
    OK
    127.0.0.1:6379> bitfield w overflow fail incrby u4 2 1
    1) (integer) 11
    127.0.0.1:6379> bitfield w overflow fail incrby u4 2 1
    1) (integer) 12
    127.0.0.1:6379> bitfield w overflow fail incrby u4 2 1
    1) (integer) 13
    127.0.0.1:6379> bitfield w overflow fail incrby u4 2 1
    1) (integer) 14
    127.0.0.1:6379> bitfield w overflow fail incrby u4 2 1
    1) (integer) 15
    127.0.0.1:6379> bitfield w overflow fail incrby u4 2 1  # 不执行
    1) (nil)
    

HyperLogLog

• 场景：统计每个网站的UV数据时，需要将UV去重。这要求每一个网页请求都要带上唯一的用户ID。假如使用set来存储访问过某一个页面的所有ID，这样做是可行的，但是如果页面访问量到达几千万甚至更高时，需要惊人的存储空间。同时，我们并不需要知道每一个访问这个页面的用户ID，并且并不需要太过精确的计数，105W和106W对我们来说并没有太大的区别

• Redis提供了HyperLogLog来解决这种统计问题，它提供了一种不太精确的去重计数方案，标准误差是0.81%，而这样的精确度已经可以满足UV统计需求了

• 使用方法

  • HyperLogLog 提供了 pfadd 、pfcount 、 pfmerge。一个是增加计数，一个是获取计数，一个是合并计数。pfadd 和 pfcount类似与集合中的 sadd 和 scard ， pfmerge用于将多个 pf 计数值累加在一起形成一个新的 pf 值。

• 注意的点

  • HyperLogLog 这个数据结构需要占据最多 12k 的存储空间，所以它不适合统计单个用户相关的数据。如果你的用户上亿，空间成本是非常惊人的。在计数比较小时，它的存储空间采用稀疏矩阵存储，空间占用很小，仅仅在计数慢慢变大，稀疏矩阵占用空间渐渐超过了阈值时才会一次性转变成稠密矩阵，才会占用 12k 的空间。

• 内存占用为什么是 12k？

  • Redis 的 HyperLogLog 实现中用到的是 16384 个桶，也就是 2^14，每个桶的 maxbits 需要 6 个 bits 来存储，最大可以表示 maxbits=63，于是总共占用内存就是2^14 * 6 / 8 = 12k字节。