redis位图详解与应用

应用场景：

1. 用户签到
2. 用户在线状态
3. 统计活跃用户
4. 各种状态值
5. 自定义布隆过滤器
6. 点赞功能

基本命令：

SETBIT

对 key 所储存的字符串值，设置或清除指定偏移量上的位(bit)。
SETBIT key offset value
offset 参数必须大于或等于 0 ，小于 2^32 (bit 映射被限制在 512 MB 之内)。

GETBIT

对 key 所储存的字符串值，获取指定偏移量上的位(bit)。
GETBIT key offset

BITCOUNT

计算给定字符串中，被设置为 1 的比特位的数量。
BITCOUNT key

BITPOS

返回位图中第一个值为 bit 的二进制位的位置。
BITPOS key bit [start] [end]

BITOP

对一个或多个保存二进制位的字符串 key 进行位元操作，并将结果保存到 destkey 上。
BITOP operation destkey key [key …]
operation 可以是 AND 、 OR 、 NOT 、 XOR 这四种操作中的任意一种
BITOP AND destkey key [key ...] ，对一个或多个 key 求逻辑并，并将结果保存到 destkey 。

BITFIELD

bitfield 有三个子指令，分别是 get/set/incrby，它们都可以对指定位片段进行读写，但是最多只能处理 64 个连续的位，如果超过 64 位，就得使用多个子指令，bitfield 可以一次执行多个子指令。

基本操作：

操作分析：

注意：位图占用空间计算，如下图：

如果key的位占够10位了，string长度为154320987字节，可以推测key占用了147M左右的内存，造成了空间上的浪费，因为100000000之前的位都没有用到，使用bitmap时要慎重。

底层数据结构分析

SDS是redis中的一种数据结构，叫做简单动态字符串（Simple Dynamic String），并且它是一种二进制安全的，在大多数的情况下redis中的字符串都用SDS来存储。

SDS的数据结构：

struct sdshdr {
 #记录buff数组中已使用字节的数量
 #也是SDS所保存字符串的长度
 int len;
 #记录buff数组中未使用字节的数量
 int free;
 #字节数组，字符串就存储在这个数组里
 char buff\[\];
}

数据存储示例：

SDS的优点：

1. 时间复杂度为O(1)

2. 杜绝缓冲区溢出

3. 减少修改字符串长度时候所需的内存重分配次数

4. 二进制安全的API操作

5. 兼容部分C字符串函数

redis中的位数组采用的是String字符串数据格式来存储，而字符串对象使用的正是上文说的SDS简单动态字符串数据结构。

大家都知道的是一个字节用的是8个二进制位来存储的，也就是8个0或者1，即一个字节可以存储十进制0~127的数字，也即包含了所有的数字、英文大小写字母以及标点符号。

1Byte=8bit 1KB=1024Byte 1MB=1024KB 1GB=1024MB

位数组在redis存储世界里，每一个字节也是8位，初始都是：

0 0 0 0 0 0 0 0

而位操作就是在对应的offset偏移量上设置0或者1，比如将第3位设置为1，即：

0 0 0 0 1 0 0 0
#对应redis操作即：
setbit key 3 1

在此基础上，如果要在偏移量为13的位置设置1，即：

setbit key 13 1
#对应redis中的存储为：
0 0 1 0 | 0 0 0 0 | 0 0 0 0 | 1 0 0 0

时间复杂度

GETBIT命令时间复杂度O(1)

STEBIT命令时间复杂度O(1)

BITCOUNT命令时间复杂度O(n)

BITOP命令时间复杂度O(n)、O(n2)

我们来看GETBIT以及SETBIT命令的时间复杂度为什么是O(1)，当我们执行一个SETBIT key 10086 1的值的时候，reids的计算方式如下：

获取到要写入位数组中的哪个字节：10086÷8=1260，需要写入到位数组的下标1260的字节

获取要写入到这个字节的第几位：10086 mod 8 = 6，需要写入到这个字节的下标为6即第7位上去。

通过这两种计算方式大家可以清晰的看到，位操作的GETBIT和SETBIT都是常量计算，因此它的时间复杂度为O(1)。

而BITCOUNT命令需要对整个位数组的所有元素进行遍历算出值为1的有多少个，当然redis对于大数据了的bit执行bitcount命令会有一整套复杂的优化的算法，但是核心思路还是这个意思，无非是减少部分遍历查询次数。比如以128位为一次遍历，那么他的遍历次数就是所有的位数除以128。

BITTOP命令则是根据不同的操作有不同的执行方式。比如AND操作，则需要查看位值为1的即可。

存储空间计算

根据上面的介绍，相信大家已经知道了基于redis的位数组数据结构存储的数据占用内存大小是怎么计算的了。比如有100亿的数据，那么它需要的字节数组：

1000000000÷8÷1024÷1024≈119.21MB

也就是存储10亿的数据只需要119MB左右的内存空间，这对于现在动辄16G、32G集群版的redis，完全没有问题。

需要注意的是，如果你的数据量不大，那就不要把起始偏移量搞的很大，这样也是占空间的，比如我们只需要存储几百条数据，但是其中的偏移量却很大，这就会造成了很大的内存空间浪费。

应用场景：

用户签到场景

每天的日期字符串作为一个key，用户Id作为offset，统计每天用户的签到情况，总的用户签到数

活跃用户数统计

用户日活、月活、留存率等均可以用redis位数组来存储，还是以每天的日期作为key，用户活跃了就写入offset为用户id的位值1。

同理月活也是如此。

用户是否在线以及总在线人数统计

同样是使用一个位数组，用户的id映射偏移量，在线标识为1，下线标识为0。即可实现用户上下线查询和总在线人数的统计

APP内用户的全局消息提示小红点

现在大多数的APP里都有站内信的功能，当有消息的时候，则提示一个小红点，代表用户有新的消息。

位图计数：

　　位图计数 的意思是统计bitmap中值为1的位的个数，位统计的效率时很高的。

redis中允许使用二进制的key和二进制的value，bitmap就是二进制的value。

 

点赞/取消点赞：

　　假设用户ID为100，对照片ID为100的照片进行点赞。首先根据照片ID生成数据存储的redis key，比如生成策略是like_photo:{photo_id}，用户ID为1000的用户点赞只需将like_photo:100的第1000位设置为1即可（取消置为0）。

　　redis setbit操作的时间复杂度为O（1），所以这种点赞方式十分高效。

当前是否点赞：

　　用户打开图片的时候需要查询当前是否点赞过该照片，查询是否点赞可以通过redis getbit操作实现。

查询点赞总次数：

　　比如需要显示照片ID为1000的照片的获赞总次数，只需对like_photo:1000进行位图计数操作即可：bitcount。时间复杂度为O(N)。个人以为可以在照片表中加一个字段记录获赞总次数，这样就不用循环统计各个照片的获赞次数。

redis还提供了bittop等其他一些API，可以实现一些有趣的事。

局限性：

　　当用户量很大的时候，比如千万级用户量的时候，最坏的情况下一个点赞bitmap需要消耗的内存为10000000/8/1024/1024=1.19MB,