《Redis深度历险》布隆过滤器,简单限流

布隆过滤器

如果需要依据需要判断某个信息存不存在,则就无法使用HyperLogLog,它只能估测出大概存在多少个不同的值,但是由于数据都被处理过了,无法进行还原,且基于一定的概率性。
比如如果需要对用户数据推荐某些东西,而不能推荐一些重复的内容时,HyperLogLog就无法使用了,这时就需要使用到布隆过滤器了,它是一种高级数据结构,布隆过滤器课节省90%的空间,只是稍微有点不精确,存在一定的误判率。

是什么

不是完全精确的SET
可能会把没存在过的误判为存在,不会把存在误判不存在。
在上述场景中,就可能会漏推荐一些内容。

Redis中的布隆过滤器

基本命令 bf.addbf.existsbf.madd,bf.mexists;
可使用bf.reserve 命令设定key,error_rate,initial_size. error_rate为容错率,设置得越低越精确可是会越耗费空间,不过不是完全精准的,略高一点是能够允许的,initial_size是预计放入的元素数量,如果真实数量超出此大小了,则会影响准确率。

原理

看亚子作者比较喜欢布隆过滤器,这章就介绍得稍微详细些。
简单的说就是用多个无偏的Hash函数,对添加的元素计算Hash值,然后对数组长度取模,每个会映射多个位置,置为1,如果一个重复的key算出的hash值肯定在数组中是被置为1的,不过不重复的key也因为这个原因可能映射的位置也已经被其他置1了。
如果数组中比较稀疏时准确率还是比较可观的,如果拥挤的话,情况就会越来越糟。使用的多个hash函数的目的是为了使映射充分的散列开来。
所以当实际数量远超于初始数量时,就需要对布隆过滤器进行重建,重新分配一个更大的过滤器。再将所有值批量插入其中。

空间占用估计

原理中的数组的长度并不与预计数量等价。

k≈0.7*(l/n); l数组长度,n预计元素个数,k所需hash函数数量
f=0.6185^(l/n);  f容错率
实际元素超出时,误判率会怎样变化

错误率原本置于较低就会上升得比较慢,因为k越大。
大致符合这个公式:f = (1-0.5x)k x为实际元素与预计元素的倍数。

其他应用

网页爬虫,垃圾邮件过滤功能(所以一些正常邮件可能会被误判为垃圾…)。

简单限流

系统性能有限,所以阻止一部分计划外的请求是需要考虑的一个问题,除了控制流量还有限行用户行为的作用,避免垃圾请求。在一定的时间内只能进行有限次的某操作,超出的都是非法相应,予以拒绝。
本来我想的是给定一个字符串,设定过期时间,在时间范围内不允许再操作,等待过期…
书中给定的方案是使用zset,value来存储毫秒时间戳,只保留在滑动窗口内的值。如果没有值了则移除内存。

如果规定时间内的操作极多(比如60秒内允许操作100万次),则会耗费大量内存。

public class SimpleRateLimiter {
    private Jedis jedis;

    public SimpleRateLimiter(Jedis jedis){
        this.jedis = jedis;
    }

    public boolean isActionAll(String userId,String actionKey,int period,int maxCount){
        String key = String.format("hist:%s:%s",userId,actionKey);
        long nowTs = System.currentTimeMillis();
        //pipeline就是把一组命令进行打包
        //然后一次性通过网络发送到Redis。同时将执行的结果批量的返回回来
        Pipeline pipe = jedis.pipelined();
        //multi代表事务开始
        pipe.multi();
        //key score member
        pipe.zadd(key,nowTs,""+nowTs);
        //规定的时间宽度内有多少个元素
        pipe.zremrangeByScore(key,0,nowTs-period*1000);
        Response<Long> count = pipe.zcard(key);
        //设置过期时间
        pipe.expire(key,period+1);
        //exec事务结束
        pipe.exec();
        pipe.clear();
        return count.get()<=maxCount;
    }

    public static void main(String[] args) {
        Jedis jedis = new Jedis();
        SimpleRateLimiter limiter = new SimpleRateLimiter(jedis);
        for(int i=0;i<20;i++){
            System.out.println("i: "+limiter.isActionAll("yuan","ddd",60,5));
        }
    }
}
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
概要介绍: 本课程主要是介绍并实战一款java中间件~redisson,介绍redisson相关的核心技术栈及其典型的应用场景,其中的应用场景就包括布隆过滤器限流器、短信发送、实时/定时邮件发送、数据字典、分布式服务调度等等,在业界号称是在java项目里正确使用redis的姿势。本课程的目标就在于带领各位小伙伴一起学习、攻克redisson,更好地巩固自己的核心竞争力,而至于跳槽涨薪,自然不在话下!  课程内容: 说起redisson,可能大伙儿不是很熟悉,但如果说起redis,想必肯定很多人都晓得。没错,这家伙字如其名,它就是架设在redis基础上的一款综合性的、新型的中间件,号称是java企业级应用开发中正确使用redis的姿势/客户端实例。 它是架设在redis基础之上,但拥有的功能却远远多于原生Redis 所提供的,比如分布式对象、分布式集合体系、分布式锁以及分布式服务调度等一系列具有分布式特性的对象实例… 而这些东西debug将在本门课程进行淋漓尽致的介绍并实战,除此之外,我们将基于spring boot2.0搭建的多模块项目实战典型的应用场景:对象存储、数据字典、短信发送、实时/定时邮件发送、布隆过滤器限流组件、分布式服务调度....课程大纲如下所示: 下面罗列一下比较典型的核心技术栈及其实际业务场景的实战,如下图所示为redisson基于订阅-发布模式的核心技术~主题Topic的实际业务场景,即实时发送邮件: 而下图则是基于“多值映射MultiMap”数据结构实战实现的关于“数据字典”的缓存管理: 除此之外,我们还讲解了可以与分布式服务调度中间件dubbo相媲美的功能:分布式远程服务调度,在课程中我们动手搭建了两个项目,用于分别充当“生产者”与“消费者”角色,最终通过redisson的“服务调度组件”实现服务与服务之间、接口与接口之间的调用!  课程收益: (1)认识并掌握redisson为何物、常见的几种典型数据结构-分布式对象、集合、服务的应用及其典型应用场景的实战; (2)掌握如何基于spring boot2.0整合redisson搭建企业级多模块项目,并以此为奠基,实战企业级应用系统中常见的业务场景,巩固相应的技术栈! (3)站在项目管理与技术精进的角度,掌握对于给定的功能模块进行业务流程图的绘制、分析、模块划分、代码实战与性能测试和改进,提高编码能力与其他软实力; (4)对于Java微服务、分布式、springboot精进者而言,学完本课程,不仅可以巩固提高中间件的实战能力,其典型的应用场景更有助于面试、助力相关知识点的扫盲! 如下图所示: 关键字:Spring Boot,Redis,缓存穿透,缓存击穿,缓存雪崩,红包系统,Mybatis,高并发,多线程并发编程,发送邮件,列表List,集合Set,排行榜,有序集合SortedSet,哈希Hash ,进阶实战,面试,微服务、分布式 适用人群:redisson学习者,分布式中间件实战者,微服务学习者,java学习者,spring boot进阶实战者,redis进阶实战者
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值