bitmapredisRedis中BitMap技术简介及应用
老铁们,大家好,相信还有很多朋友对于bitmap
redis和Redis中BitMap技术简介及应用的相关问题不太懂,没关系,今天就由我来为大家分享分享bitmap redis以及Redis中BitMap技术简介及应用的问题,文章篇幅可能偏长,希望可以帮助到大家,下面一起来看看吧!本文目录
redis bitmap 存放手机号Redis中BitMap技术简介及应用Redis使用bitmap、zset、hash、list等结构完成骚操作redisbitmap缺点redis bitmap 存放手机号直接存放会导致超限.>2^32= 4294967296(10位)=512MB,约40亿.
所以可以采取分段存储:
国内的手机号大部分是以13,14,15,16,17,18,19等开头,前2位一般都是固定的。
前2位的存储空间为:99=99/1024/8= 0.012KB
后9位的存储空间为:999999999 = 999999999/1024/1024/8=119.2MB
前3位的存储空间为:999=999/1024/8=0.12KB
后8位的存储空间为:99999999 = 99999999/1024/1024/8=11.92MB
如:手机号:15141048700表示为:151 41048700
redis指令如下:
Redis中BitMap技术简介及应用BitMap是一串连续的二进制数字(0和1),类似于位数组,每一位所在的位置为偏移量(offset),类似于数组索引,BitMap就是通过最小的单位bit来进行0|1的设置,时间复杂度位O(1),表示某个元素的值或者状态。由于bit是计算机中最
小的单位,使用它进行储存将非常节省空间。特别适合一些数据量大的场景。例如,统计每日活跃用户、统计每月打卡数等统计场景。1天记录1000W用户的活跃统计数据,只需要10000000/8/1024/1024≈1.2M。Redis从2.2.0版本开始新增了setbit,getbit,bitcount,bitop等几个BitMap相关命令,虽然是新命令,但是并没有增加新的数据类型,它还是属于String类型。Redis中的BitMap最大占用内存大小限制在512M之内,即2^32。
设置某个key的指定偏移量的value值为0或者1,key不存在时自动生成一个新的字符串值,字符串会进行伸展,该偏移量前面的位值默认为0,偏移量offset参数必须大于等于0,小于2^32。
时间复杂度:O(1)
返回值:指定偏移量存储的值
示例:
获取key指定偏移量上的值,当key不存在时,返回0。
时间复杂度:O(1)
返回值:指定偏移量上存储的值
示例:
统计给定key中,被设置为1的比特位的数量,可以通过start和end参数设置范围。
时间复杂度:O(n)
返回值:key中被设置为1的数量
示例:
对一个或多个key进行位操作,并将结果保存到destkey上。操作方式可以是AND、OR、NOT、XOR这四种,除了NOT操作之外,其他操作可接收多个key。
时间复杂度:O(n)
返回值:保存到destkey的字符串的长度
示例:
签到需求:
之前的应用都是统计总数,但如果业务需要,有时也可能需要获取用户ID,来做下一步操作。
Redis使用bitmap、zset、hash、list等结构完成骚操作当同时满足以下条件时,使用ziplist编码:
SpringBoot—实现n秒内出现x个异常报警
思路:
借助Redis的zSet集合,score存储的是异常时的时间戳,获取一定时间范围内的set集合。判断set个数是否满足条件,若满足条件则触发报警;
注意点:
相关API:
Redis实现延迟队列方法介绍
基于Redis实现DelayQueue延迟队列设计方案
相关API:
SpringBoot2.x—使用Redis的bitmap实现布隆过滤器(Guava中BF算法)
布隆过滤器:是专门用来检测集合中是否存在特定元素的数据结构。
存在误差率:即将不在集合的元素误判在集合中。
所以布隆过滤器适合查询准确度要求没这么苛刻,但是对时间、空间效率比较高的
场景。实现方式:Redis实现布隆过滤器——借鉴Guava的BF算法:
SpringBoot2.x中使用Redis的bitmap结构(工具类)
注意:bitmap使用存在风险,若仅仅计算hash值,会导致bitmap占用空间过大。一般需要对hash值进行取余处理。
根据Redis是否存在key,判断锁是否被获取;
锁应该是一个对象,记录持有锁的线程信息、当前重入次数。所以应该使用Redis的Hash结构来存储锁对象。
3.1网络波动造成释放锁失败怎么解决?
需要为锁加上超时时间;
3.2任务未执行完毕时,锁由于超时时间被释放?
线程一旦加锁成功,可以启动一个后台线程,每隔多少秒检查一次,如果线程还持有锁,可以不断延长锁的生存时间。
主从切换时,从服务器上没有加锁信息,导致多个客户端同时加锁。
list结构底层是ziplist/quicklist(可看着一个双端队列)。常用命令:
使用list作为对象的缓存池。通过rpush放入对象,通过lpop取出对象。
若是阻塞取,可以使用blpop命令实现。
Redis和Lua脚本(实现令牌桶限流)
数据结构选择hash。
hash里面维护:最后放入令牌时间、当前桶内令牌量、桶内最大数量、令牌放置速度(元数据)。
被动式维护:
命令:incr原子累加;
对一段固定时间窗口内的请求进行计数,如果请求数超过了阈值,则舍弃该请求;如果没有达到设定的阈值,则接受该请求,且计数加1。当窗口时间结束,重置计数器为0。
优点:实现简单,容易理解;
缺点:流量曲线可能不够平滑,有“突刺现象”。
1.一段时间内(不超过时间窗口)系统服务不可用。比如窗口大小1s,限流为100,恰好某个窗口第1ms来了100个请求,然后2ms-999ms请求都会被拒绝。这段时间用户会感觉系统服务不可用(即不够平滑)。
2.窗口切换时可能会出现两倍于阈值流量的请求。比如窗口大小1s,限流大小100,然后在某个窗口的第999ms有100个请求,窗口前期没有请求。所以这100个请求都会通过。然后下一个窗口的第1ms又来100个请求,然后全部通过。其实也是1ms内通过的200个请求。
命令:Redis的incr命令
是对固定窗口计数器的优化,解决的是切换窗口两倍阈值流量的场景。
具体解决方案是:将限流窗口分为多个小的限流窗口,各个限流窗口分别计数。当前时间大于窗口最大时间时,将头部的小窗口数据舍弃,尾部新增小窗口来处理新请求。
优点:本质上是对固定窗口的优化
redisbitmap缺点redisbitmap有缺点。根据查询相关公开信息:用BITPOS有一个缺点,那就是每次只能找到一个为1的下标,因此,当我们需要统计处bitmap中有哪些位置为1的时候,则需要使用一些额外的代码计算。
好了,文章到此结束,希望可以帮助到大家。