你真的会使用Redis的BitMap么？

傲浮刷题

已于 2022-12-14 09:38:28 修改

阅读量323

点赞数

文章标签： redis java 数据库

于 2022-12-14 09:23:58 首次发布

本文链接：https://blog.csdn.net/weixin_42119706/article/details/128302787

版权

你真的会使用Redis的BITMAP么？

前言

这是一篇拖了很久的总结，项目中引入了redis的bitmap的用法，感觉挺高大上的，刨根问底，故留下总结一篇当作纪念。

首先来说位图（Bitmap），即位（Bit）的集合，是一种数据结构，可用于记录大量的0-1状态，在很多地方都会用到，比如Linux内核（如inode，磁盘块）、Bloom Filter算法等，其优势是可以在一个非常高的空间利用率下保存大量0-1状态。

说清楚几个问题：

bitmap的原理、用法。
bitmap的优势、限制。
bitmap空间、时间粗略计算方式。
bitmap的使用场景。

BITMAP的原理、用法

原理

首先简单回顾一下二进制的一些知识：

1byte = 8bit

一个bit有2种状态，0 或者 1

所以1个byte可以表示0000 0000 -> 1111 1111, 也就是十进制的 0 到 255

其中十进制和二进制对应关系如下：

0 ---------> 0000 0000
 1 ---------> 0000 0001
 2 ---------> 0000 0010
 3 ---------> 0000 0011
 4 ---------> 0000 0100
 5 ---------> 0000 0101
 6 ---------> 0000 0110
 7 ---------> 0000 0111
 8 ---------> 0000 1000
 9 ---------> 0000 1001
.......................
255...........1111 1111

BitMap 的基本原理就是用一个bit 位来存放某种状态，适用于大规模数据，但数据状态又不是很多的情况。通常是用来判断某个数据存不存在的。

举例：在Java里面一个int类型占4个字节，假如要对于10亿个int数据进行处理呢？10亿*4/1024/1024/1024=4个G左右，需要4个G的内存。

如果能够采用bit储,那么10_0000_0000Bit = 1_2500_0000byte = 122070KB = 119MB, 那么在存储空间方面可以大大节省。

在Java里面，BitMap已经有对应实现的数据结构类java.util.BitSet，BitSet的底层使用的是 long 类型的数组来存储元素。

对于1，3，5，7这四个数，如果存在的话，则可以这样表示：

首先我们看下空字节的样子

0	0	0	0	0	0	0	0
0	1	2	3	4	5	6	7

那么1，3，5，7这几个数在这个字节中应该时下面这个样子

0	1	0	1	0	1	0	1
0	1	2	3	4	5	6	7

1代表这个数存在，0代表不存在。

例如表中01010101代表1，3，5，7存在，0，2，4，6不存在。那如果8，10，14也存在怎么存呢？8，10，14我们可以存在第二个字节里

1	0	1	0	0	0	1	0
8	9	10	11	12	13	14	15

Map映射表

假设需要排序或者查找的总数N=10000000，那么我们需要申请内存空间的大小为int a[1 + N/32]，其中：a[0]在内存中占32为可以对应十进制数0-31，依次类推： bitmap表为：

a[0]--------->0-31
a[1]--------->32-63
a[2]--------->64-95
a[3]--------->96-127

在redis中的用法

GETBIT

最早可用版本：2.2.0。时间复杂度：O(1)。

语法格式：

GETBIT key offset

获取 key 对应第 offset 位的值（offset 从 0 开始算）。当 offset 超过字符串长度时，字符串假定为一个 0 位的连续空间。当指定的 key 不存在时，假定为一个空字符串，offset 肯定是超出字符串长度范围，因此该值也被假定为 0 位的连续空间，都会返回 0。

下面获取用户id为 4 的用户是否在 20220514 这天登录过，返回 0 说明没有访问过：

127.0.0.1:6379> getbit login:20220514 4
(integer) 0

下面获取用户id为 5 的用户是否在 20220514 这天登录过，返回 1 说明访问过：

127.0.0.1:6379> getbit login:20220514 5

BITCOUNT

最早可用版本：2.6.0。时间复杂度：O(N)。

语法格式

BITCOUNT key [ start end [ BYTE | BIT]]

用来计算指定 key 对应字符串中，被设置为 1 的 bit 位的数量。一般情况下，字符串中所有 bit 位都会参与计数，我们可以通过 start 或 end 参数来指定一定范围内被设置为 1 的 bit 位的数量。start 和 end 参数的设置和 GETRANGE 命令类似，都可以使用负数：比如 -1 表示最后一个位，而 -2 表示倒数第二个位等。

从 Redis 7.0.0 开始支持 BYTE 或者 BIT 选项

下面计算 20220514 这天所有登录用户数量：

127.0.0.1:6379> bitcount login:20220514

BITOP

最早可用版本：2.6.0。时间复杂度：O(N)。

语法格式：

BITOP operation destkey key [key ...]

BITOP 是一个复合操作，支持在多个 key 之间执行按位运算并将结果存储在 destkey 指定的 key 中。BITOP 命令支持四种按位运算：AND(交集)、OR(并集)、XOR(异或) 和 NOT(非)：

BITOP AND destkey srckey1 srckey2 srckey3 ... srckeyN
BITOP OR destkey srckey1 srckey2 srckey3 ... srckeyN
BITOP XOR destkey srckey1 srckey2 srckey3 ... srckeyN
BITOP NOT destkey srckey

如上所见，NOT 很特殊，因为它只需要一个输入 key，因为它执行位反转，因此它仅作为一元运算符才有意义。

可以使用 AND 求交集，具体命令如下：

127.0.0.1:6379> bitop and login:20220513:and:20220514 login:20220513 login:20220514
(integer) 2
127.0.0.1:6379> bitcount login:20220513:and:20220514
(integer) 2
127.0.0.1:6379> getbit login:20220513:and:20220514 1
(integer) 1
127.0.0.1:6379> getbit login:20220513:and:20220514 5
(integer) 1

可以使用 OR 求并集，具体命令如下：

127.0.0.1:6379> bitop or login:20220513:or:20220514 login:20220513 login:20220514
(integer) 2
127.0.0.1:6379> bitcount login:20220513:or:20220514
(integer) 7
127.0.0.1:6379> getbit login:20220513:or:20220514 0
(integer) 1
127.0.0.1:6379> getbit login:20220513:or:20220514 1
(integer) 1

BITPOS

最早可用版本：2.8.7。时间复杂度：O(N)。

语法格式：

BITPOS key bit [ start [ end [ BYTE | BIT]]]

用来计算指定 key 对应字符串中，第一位为 1 或者 0 的 offset 位置。除此之外，BITPOS 也有两个选项 start 和 end，跟 BITCOUNT 一样。

BYTE、BIT 这两个选项从 7.0.0 版本开始才能使用。

下面计算 20220514 登录 App 的最小用户id：

127.0.0.1:6379> bitpos login:20220513 1

bitmap的优势、限制。

优势

1.基于最小的单位bit进行存储，所以非常省空间。
2.设置时候时间复杂度O(1)、读取时候时间复杂度O(n)，操作是非常快的。
3.二进制数据的存储，进行相关计算的时候非常快。
4.方便扩容

限制

redis中bit映射被限制在512MB之内，所以最大是2^32位。建议每个key的位数都控制下，因为读取时候时间复杂度O(n)，越大的串读的时间花销越多。

bitmap空间、时间粗略计算方式。

在一台2010MacBook Pro上，offset为2^{32-1（分配512MB）需要～300ms，offset为2}30-1(分配128MB)需要～80ms，offset为2^{28-1（分配32MB）需要～30ms，offset为2}26-1（分配8MB）需要8ms。<来自官方文档>

大概的空间占用计算公式是：($offset/8/1024/1024)MB

BITMAP的使用场景

常规场景

（1）给定10亿个不重复的正int的整数，没排过序的，然后再给一个数，如何快速判断这个数是否在那10亿个数当中。

解法：遍历40个亿数字，映射到BitMap中，然后对于给出的数，直接判断指定的位上存在不存在即可。

（2）使用位图法判断正整形数组是否存在重复

解法：遍历一遍，存在之后设置成1，每次放之前先判断是否存在，如果存在，就代表该元素重复。

（3）使用位图法进行元素不重复的正整形数组排序

解法：遍历一遍，设置状态1，然后再次遍历，对状态等于1的进行输出，参考计数排序的原理。

（4）在2.5亿个整数中找出不重复的正整数，注，内存不足以容纳这2.5亿个整数

解法1：采用2-Bitmap（每个数分配2bit，00表示不存在，01表示出现一次，10表示多次，11无意义）。

解法2：采用两个BitMap，即第一个Bitmap存储的是整数是否出现，接着，在之后的遍历先判断第一个BitMap里面是否出现过，如果出现就设置第二个BitMap对应的位置也为1，最后遍历BitMap，仅仅在一个BitMap中出现过的元素，就是不重复的整数。

解法3：分治+Hash取模，拆分成多个小文件，然后一个个文件读取，直到内存装的下，然后采用Hash+Count的方式判断即可。

该类问题的变形问题，如已知某个文件内包含一些电话号码，每个号码为8位数字，统计不同号码的个数。8位最多99 999 999，大概需要99m个bit，大概10几m字节的内存即可。（可以理解为从0-99 999 999的数字，每个数字对应一个Bit位，所以只需要99M个Bit==12MBytes，这样，就用了小小的12M左右的内存表示了所有的8位数的电话）

具体场景

1、用户在线状态

需要对子项目提供一个接口，来提供某用户是否在线？

使用bitmap是一个节约空间效率又高的一种方法，只需要一个key，然后用户id为偏移量offset，如果在线就设置为1，不在线就设置为0，3亿用户只需要36MB的空间。

$status = 1;

$redis->setBit('online', $uid, $status); 

$redis->getBit('online', $uid);

需要加上如例子1一样分片的方式。10亿真的太多了。10w分一片。

2、统计活跃用户

需要计算活跃用户的数据情况。

使用时间作为缓存的key，然后用户id为offset，如果当日活跃过就设置为1。之后通过bitOp进行二进制计算算出在某段时间内用户的活跃情况。

$status = 1;
$redis->setBit('active_20170708', $uid, $status);
$redis->setBit('active_20170709', $uid, $status);
$redis->bitOp('AND', 'active', 'active_20170708', 'active_20170709');

上亿用户需要加上如例子1一样分片的方式。几十万或者以下，可无需分片省的业务变复杂。

3、用户签到

用户需要进行签到，对于签到的数据需要进行分析与相应的运运营策略。

使用redis的bitmap,由于是长尾的记录，所以key主要由uid组成，设定一个初始时间，往后没加一天即对应value中的offset的位置。

$start_date = '20170708';
$end_date = '20170709';
$offset = floor((strtotime($start_date) - strtotime($end_date)) / 86400);
$redis->setBit('sign_123456', $offset, 1);

//算活跃天数
$redis->bitCount('sign_123456', 0, -1)

无需分片，一年365天，3亿用户约占300000000*365/8/1000/1000/1000=13.68g。存储成本是不是很低。