赞
踩
作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO
联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬
学习必须往深处挖,挖的越深,基础越扎实!
阶段1、深入多线程
阶段2、深入多线程设计模式
阶段3、深入juc源码解析
码哥源码部分
码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】
码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】
码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作?】
码哥讲源码【谁再说Spring不支持多线程事务,你给我抽他!】
打脸系列【020-3小时讲解MESI协议和volatile之间的关系,那些将x86下的验证结果当作最终结果的水货们请闭嘴】
我们在第一篇 深刻理解高性能Redis的本质 的时候就介绍过Redis的几种基本数据结构,它是基于不同业务场景而设计的:
除了这常见数据类型,还有一些不常用的数据类型,如 BitMap、Geo、HyperLogLog 等等,他们在各自的领域为大数据量的统计,后面我们一一来介绍,学习下他们的实现原理和应用场景。
BitMap (位图)的底层数据结构使用的是String类型的的 SDS 数据结构来保存。因为一个字节8个bit位,为了有效的将字节的8个bit都利用到位,使用数组模式存储。
并且每个bit都使用二值状态表示,要么0,要么1。
所以,BitMap 是通过一个 bit 位来表示某个元素对应的值或者状态, 它的结构如下,key 对应元素本身;offset即是偏移量,固定整型,一般存数组下表或者唯一值;value存储的是二值(要么0要么1),一般用来表示状态,如性别、是否登录、是否打卡等。
从上面可以看出这边使用一个字节表示1行,每1行存储8个bit,就是可以存储8个状态位,极大的提高了空间利用。这也是BitMap的优势,我们可以使用很少的字节,存储大量的在线状态、打卡标记等状态信息,非常有效果。
我们可以使用 setbit, getbit, bitcount 等几个相关命令来管理BitMap。语法如下:
SETBIT key offset value
上面说过了,key是元素名称, offset 必须是数值类型,value 只能是 0 或者 1,如果我们存储一个用户的在线状态,用户,代码如下:
- //设置在线状态
- // $redis->setBit('online', $uid, 1);
-
- $redis->setBit('online', 5, 1);
- $redis->setBit('online', 9, 1);
则具体体现为:
byte | bit0 | bit1 | bit2 | bit3 | bit4 | bit5 | bit6 | bit7 |
---|---|---|---|---|---|---|---|---|
buf[0] | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 |
buf[1] | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 |
可以看出用户ID为5和9被打上1的标志,代表在线状态,其他未设置值默认为0,是离线状态。
除了Set之外,还有getBit、bitCount等语法,如下:
- // 获取是否在线的状态
- $isOnline = $redis->getBit('online', $uid);
-
- // 获取在线人数 统计
- $onlineNum = $redis->bitCount('online');
上面介绍了BitMap的原理和状态存储的优势。那我们存储了bit位,其实目的还是为了高效的计算,而不是简单的状态记录。
而在实际的应用场景中,他主要解决如下几个类型的需求:
上面其实我们已经演示过了,这种场景最常见,因为值只能是1或者0,所以所有的二值状态的,所有存在是否对照关系的场景都可以使用。如在线(1) 离线(0),打卡(1) 未打卡(0),登录(1) 未登录(0),群聊消息已阅(1) 未阅(0) 等等。
我们以用户 离线/在线 为例子,看看如何使用 Bitmap 在海量的用户数据之中判断某个用户是否是在线状态。
假设我们使用一个 online_statu
来作为key,用来存储 用户登录后的状态集合,而用户的ID则为offset,online的状态就用1表示,offline的状态就用0表示。
SETBIT online_statu 1024 1
- GETBIT online_statu 1024
SETBIT online_statu 1024 0
基于上面的讨论,我们可以总结出一个预评估公式,根据实际的数据量获取存储空间:( offset / 8 / 1024 / 1024 ) M
固定周期可能是年/月/周,按照不同维度,可能有 365,31,7的bit位的统计周期。
假设这时候我们如果对于某个用户(如1024)全年的签到情况做统计,可以这么设计:
- # 22年第一天
- SETBIT sign_1024_2022 0 1
-
- # 22年最后一天
- SETBIT sign_1024_2022 364 1
GETBIT sign_1024_2022 150
BITCOUNT sign_1024_2022
$index = BITPOS sign_1024_2022 30
offset也是从0开始的,所以返回的值最好加个1,不会让用户看的晕头转向。
如果一个平台有千万级别以上的大量用户,而我们需要统计每个用户连续签到的信息,那需要怎么设计呢?
如果这时候我们要判断用户是否整周都有签到或者整个月都有签到就可以使用 【与】运算
只有指定周期内的所有值都是1(签到)的时候,结果才是1,否则是我们整周或者整个月都拿起来【与】运算,得到的结果是不是1就能确是否满勤。
- # 与运算: 0&0=0;0&1=0;1&0=0;1&1=1
- # 下面为伪代码,类似:
- (20221022 1024) & ( 20221023 1024) & ...
Redis 提供了 BITOP operation destkey key [key ...]这个指令用于对一个或者多个 键 = key 的 Bitmap 进行 位元 操作。
operation 可以是 AND 、 OR 、 NOT 、 XOR 这四种操作中的任意一种:
除了 NOT 操作之外,其他操作都可以接受一个或多个 key 作为输入。
- # 统计一周的值(7个BitMap,10.17 ~ 10.23 号)并将结果存入到新的BitMap (sign-result) 中
- redis> BITOP AND sign-result 20221017 20221018 20221019 20221020 20221021 20221022 20221023
- (integer) 1
-
- # 新的BitMap 中,获取 1024的签到结果,如果为1,则本周全部签到
- redis> GETBIT sign-result 1024
- (integer) 1
可以理解下这张图的运算过程:
这边需要注意:当 BITOP 处理不同长度的字符串时,较短字符串所缺部分会被当作 0 对待。同样的,空 key 也被看作是 0 的字符串序列看待。
同理,类似HeapDump性能社区的用户签到统计,也可以用位图(BitMap)这种方式计算!
1个byte等于8个bit,每个bit位只使用0或者1来表示,这样能够有效的降低存储空间,而Redis是存储在高速缓存中的,所以实际上是大大减少了内存占用。
很多场景都可以使用位图计算,比如我们上面说到的 是否登录、是否在线、是否签到、用户性别状态、IP黑名单、是否VIP用户统计 等等场景,但凡涉及到二值状态识别、海量统计的数据都可以考虑使用。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。