Redis-避免缓存穿透的利器之BloomFilter

Redis-避免缓存穿透的利器之BloomFilter

你知道的越多,你不知道的也越多

点赞再看,养成习惯

前言

你在开发或者面试过程中,有没有遇到过海量数据需要查重缓存穿透怎么避免等等这样的问题呢?下面这个东西超屌,好好了解下,面试过关斩将,凸显你的不一样。

Bloom Filter 概念

布隆过滤器(英语:Bloom Filter)是1970年由一个叫布隆的小伙子提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法,缺点是有一定的误识别率和删除困难。

Bloom Filter 原理

布隆过滤器的原理是,当一个元素被加入集合时,通过K个散列函数将这个元素映射成一个位数组中的K个点,把它们置为1。检索时,我们只要看看这些点是不是都是1就(大约)知道集合中有没有它了:如果这些点有任何一个0,则被检元素一定不在;如果都是1,则被检元素很可能在。这就是布隆过滤器的基本思想。

Bloom Filter跟单哈希函数Bit-Map不同之处在于:Bloom Filter使用了k个哈希函数,每个字符串跟k个bit对应。从而降低了冲突的概率。

 

img

 

 

缓存穿透

 

 

 

每次查询都会直接打到DB

简而言之,言而简之就是我们先把我们数据库的数据都加载到我们的过滤器中,比如数据库的id现在有:1、2、3

那就用id:1 为例子他在上图中经过三次hash之后,把三次原本值0的地方改为1

下次数据进来查询的时候如果id的值是1,那么我就把1拿去三次hash 发现三次hash的值,跟上面的三个位置完全一样,那就能证明过滤器中有1的

反之如果不一样就说明不存在了

那应用的场景在哪里呢?一般我们都会用来防止缓存击穿

简单来说就是你数据库的id都是1开始然后自增的,那我知道你接口是通过id查询的,我就拿负数去查询,这个时候,会发现缓存里面没这个数据,我又去数据库查也没有,一个请求这样,100个,1000个,10000个呢?你的DB基本上就扛不住了,如果在缓存里面加上这个,是不是就不存在了,你判断没这个数据就不去查了,直接return一个数据为空不就好了嘛。

这玩意这么好使那有啥缺点么?有的,我们接着往下看

Bloom Filter的缺点

bloom filter之所以能做到在时间和空间上的效率比较高,是因为牺牲了判断的准确率、删除的便利性

  • 存在误判,可能要查到的元素并没有在容器中,但是hash之后得到的k个位置上值都是1。如果bloom filter中存储的是黑名单,那么可以通过建立一个白名单来存储可能会误判的元素。

  • 删除困难。一个放入容器的元素映射到bit数组的k个位置上是1,删除的时候不能简单的直接置为0,可能会影响其他元素的判断。可以采用Counting Bloom Filter

Bloom Filter 实现

布隆过滤器有许多实现与优化,Guava中就提供了一种Bloom Filter的实现。

在使用bloom filter时,绕不过的两点是预估数据量n以及期望的误判率fpp,

在实现bloom filter时,绕不过的两点就是hash函数的选取以及bit数组的大小。

对于一个确定的场景,我们预估要存的数据量为n,期望的误判率为fpp,然后需要计算我们需要的Bit数组的大小m,以及hash函数的个数k,并选择hash函数

(1)Bit数组大小选择

  根据预估数据量n以及误判率fpp,bit数组大小的m的计算方式:

img

 

 

(2)哈希函数选择

​ 由预估数据量n以及bit数组长度m,可以得到一个hash函数的个数k:

img

 

 

​ 哈希函数的选择对性能的影响应该是很大的,一个好的哈希函数要能近似等概率的将字符串映射到各个Bit。选择k个不同的哈希函数比较麻烦,一种简单的方法是选择一个哈希函数,然后送入k个不同的参数。

哈希函数个数k、位数组大小m、加入的字符串数量n的关系可以参考Bloom Filters - the mathBloom_filter-wikipedia

要使用BloomFilter,需要引入guava包:

 <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>23.0</version>
 </dependency>    
复制代码

测试分两步:

1、往过滤器中放一百万个数,然后去验证这一百万个数是否能通过过滤器

2、另外找一万个数,去检验漏网之鱼的数量

/**
 * 测试布隆过滤器(可用于redis缓存穿透)
 * 
 * @author 敖丙
 */
public class TestBloomFilter {

    private static int total = 1000000;
    private static BloomFilter<Integer> bf = BloomFilter.create(Funnels.integerFunnel(), total);
//    private static BloomFilter<Integer> bf = BloomFilter.create(Funnels.integerFunnel(), total, 0.001);

    public static void main(String[] args) {
        // 初始化1000000条数据到过滤器中
        for (int i = 0; i < total; i++) {
            bf.put(i);
        }

        // 匹配已在过滤器中的值,是否有匹配不上的
        for (int i = 0; i < total; i++) {
            if (!bf.mightContain(i)) {
                System.out.println("有坏人逃脱了~~~");
            }
        }

        // 匹配不在过滤器中的10000个值,有多少匹配出来
        int count = 0;
        for (int i = total; i < total + 10000; i++) {
            if (bf.mightContain(i)) {
                count++;
            }
        }
        System.out.println("误伤的数量:" + count);
    }

}
复制代码

运行结果:

 

img

 

 

运行结果表示,遍历这一百万个在过滤器中的数时,都被识别出来了。一万个不在过滤器中的数,误伤了320个,错误率是0.03左右。

看下BloomFilter的源码:

public static <T> BloomFilter<T> create(Funnel<? super T> funnel, int expectedInsertions) {
        return create(funnel, (long) expectedInsertions);
    }  

    public static <T> BloomFilter<T> create(Funnel<? super T> funnel, long expectedInsertions) {
        return create(funnel, expectedInsertions, 0.03); // FYI, for 3%, we always get 5 hash functions
    }

    public static <T> BloomFilter<T> create(
          Funnel<? super T> funnel, long expectedInsertions, double fpp) {
        return create(funnel, expectedInsertions, fpp, BloomFilterStrategies.MURMUR128_MITZ_64);
    }

    static <T> BloomFilter<T> create(
      Funnel<? super T> funnel, long expectedInsertions, double fpp, Strategy strategy) {
     ......
    }
复制代码

BloomFilter一共四个create方法,不过最终都是走向第四个。看一下每个参数的含义:

funnel:数据类型(一般是调用Funnels工具类中的)

expectedInsertions:期望插入的值的个数

fpp 错误率(默认值为0.03)

strategy 哈希算法(我也不懂啥意思)Bloom Filter的应用

在最后一个create方法中,设置一个断点:

 

img

 

 

 

img

 

 

上面的numBits,表示存一百万个int类型数字,需要的位数为7298440,700多万位。理论上存一百万个数,一个int是4字节32位,需要481000000=3200万位。如果使用HashMap去存,按HashMap50%的存储效率,需要6400万位。可以看出BloomFilter的存储空间很小,只有HashMap的1/10左右

上面的numHashFunctions,表示需要5个函数去存这些数字

使用第三个create方法,我们设置下错误率:

private static BloomFilter<Integer> bf = BloomFilter.create(Funnels.integerFunnel(), total, 0.0003);
复制代码

再运行看看:

 

img

 

 

此时误伤的数量为4,错误率为0.04%左右。

 

img

 

 

当错误率设为0.0003时,所需要的位数为16883499,1600万位,需要12个函数

和上面对比可以看出,错误率越大,所需空间和时间越小,错误率越小,所需空间和时间约大

常见的几个应用场景:

  • cerberus在收集监控数据的时候, 有的系统的监控项量会很大, 需要检查一个监控项的名字是否已经被记录到db过了, 如果没有的话就需要写入db.

  • 爬虫过滤已抓到的url就不再抓,可用bloom filter过滤

  • 垃圾邮件过滤。如果用哈希表,每存储一亿个 email地址,就需要 1.6GB的内存(用哈希表实现的具体办法是将每一个 email地址对应成一个八字节的信息指纹,然后将这些信息指纹存入哈希表,由于哈希表的存储效率一般只有 50%,因此一个 email地址需要占用十六个字节。一亿个地址大约要 1.6GB,即十六亿字节的内存)。因此存贮几十亿个邮件地址可能需要上百 GB的内存。而Bloom Filter只需要哈希表 1/8到 1/4 的大小就能解决同样的问题。

总结

布隆过滤器主要是在回答道缓存穿透的时候引出来的,文章里面还是写的比较复杂了,很多都是网上我看到就复制下来了,大家只要知道他的原理,还有就是知道他的场景能在面试中回答出他的作用就好了。

好了各位,以上就是这篇文章的全部内容了,能看到这里的人呀,都是人才,我后面会每周都更新几篇《吊打面试官》系列和Java技术栈相关的文章。如果你有什么想知道的,也可以留言给我,我一有时间就会写出来,我们共同进步。

非常感谢靓仔/靓女您能看到这里,如果这个文章写得还不错的话 求点赞 求关注 求分享求留言 (对我非常有用)各位的支持和认可,就是我创作的最大动力,我们下篇文章见,拜了个拜!


每周都会持续更新《吊打面试官》系列可以关注我的公众号第一时间阅读和催更

<think>好的,用户现在让我“细说Redis”。首先,我需要回顾之前的对话历史。用户之前询问了如何优化前后端数据库查询速度,我提到了使用Redis作为缓存机制。现在用户可能想深入了解Redis,包括它的功能、使用场景以及如何实际应用。 用户可能是开发者,或者是正在学习后端技术的人。他们可能已经对数据库有基本了解,现在想进一步学习Redis来解决性能问题。深层需求可能是想全面掌握Redis,不仅了解基本概念,还想知道如何在实际项目中应用,以及最佳实践。 接下来,我需要确定回答的结构。应该从Redis的基本定义开始,然后介绍特点、数据结构、应用场景、高可用方案、性能优化、安全运维以及使用建议。还要结合之前的优化建议,比如缓存机制,说明Redis在其中的作用。 要确保内容详细但不过于冗杂。可能需要分点列出,每个部分都有子项,比如数据结构部分要提到String、Hash等,并给出使用场景的例子。应用场景部分需要联系之前的数据库优化,比如缓存、会话管理等。 另外,用户可能对Redis的持久化和集群方案感兴趣,所以需要解释RDB和AOF,以及主从复制、哨兵和Cluster的区别。性能优化方面,可以提到管道技术和内存管理,避免常见误区,比如不要滥用keys命令。 还需要注意提醒用户安全方面的设置,比如密码认证和网络隔离,避免安全漏洞。最后,给出使用建议,比如数据量预估和监控的重要性,帮助用户合理规划。 要确保语言通俗易懂,避免过多专业术语,必要时举例说明。例如,在讲缓存雪崩时,可以举一个缓存同时失效的例子,说明如何通过随机过期时间来避免。 最后,检查内容是否符合之前系统级指令的要求,比如数学公式是否正确使用,结构是否清晰,分点是否明确。确保没有使用Markdown,但用符号来区分不同部分,保持整洁。</think>以下是关于 Redis 的详细介绍,涵盖核心特性、使用场景、技术实现和最佳实践: --- ### **一、Redis 基础概念** **Redis**(Remote Dictionary Server)是一个开源的**内存型键值数据库**,支持多种数据结构,以高性能、低延迟著称。 - **定位**:缓存、消息队列、实时数据处理等场景。 - **核心优势**:内存操作 + 单线程模型(避免锁竞争) + 异步持久化。 - **协议**:基于 RESP(REdis Serialization Protocol)通信。 --- ### **二、Redis 核心特性** 1. **数据结构丰富** | 数据结构 | 典型场景 | 示例命令 | |-------------|----------------------------------|-------------------------| | **String** | 缓存、计数器、分布式锁 | `SET`, `INCR`, `GET` | | **Hash** | 存储对象属性(如用户信息) | `HSET`, `HGETALL` | | **List** | 消息队列、最新消息列表 | `LPUSH`, `BRPOP` | | **Set** | 标签系统、共同好友 | `SADD`, `SINTER` | | **ZSet** | 排行榜、延迟队列 | `ZADD`, `ZRANGEBYSCORE` | | **BitMap** | 签到统计、用户在线状态 | `SETBIT`, `BITCOUNT` | | **HyperLogLog** | 基数统计(UV 去重) | `PFADD`, `PFCOUNT` | | **Stream** | 消息队列(支持消费者组) | `XADD`, `XREADGROUP` | 2. **持久化机制** - **RDB(快照)**:定时生成数据快照(二进制文件),恢复速度快,但可能丢失最后一次快照后的数据。 ```bash save 900 1 # 900秒内至少1次修改触发保存 ``` - **AOF(追加日志)**:记录所有写操作命令,数据完整性高,但文件较大,恢复速度慢。 ```bash appendonly yes appendfsync everysec # 每秒同步一次 ``` 3. **高可用方案** - **主从复制**:主节点(Master)异步复制数据到从节点(Slave),实现读写分离。 - **哨兵(Sentinel)**:监控主节点状态,自动故障转移(选举新 Master)。 - **Cluster 集群**:数据分片(16384 个槽),支持横向扩展,每个节点存储部分数据。 --- ### **三、Redis 典型应用场景** 1. **缓存加速** - **缓存穿透**:查询不存在的数据(如恶意攻击)→ 解决方案:布隆过滤器(Bloom Filter)拦截无效请求。 - **缓存击穿**:热点 Key 过期后高并发请求直达数据库 → 解决方案:互斥锁(`SETNX`)或永不过期 + 异步更新。 - **缓存雪崩**:大量 Key 同时过期 → 解决方案:随机过期时间(如基础过期时间 + 随机偏移量)。 2. **分布式锁** 通过 `SET key value NX EX` 实现: ```lua -- 原子性操作(加锁 + 设置过期时间) SET lock:order_123 token NX EX 30 -- 释放锁时验证 token(避免误删其他客户端的锁) if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end ``` 3. **实时排行榜** 使用 **ZSet** 实现: ```bash ZADD leaderboard 100 "user:A" # 添加分数 ZREVRANGE leaderboard 0 9 WITHSCORES # 获取 Top 10 ``` 4. **消息队列** - **List 实现简单队列**:`LPUSH` + `BRPOP`(阻塞式消费)。 - **Stream 实现高级队列**:支持多消费者组、消息确认(ACK)和消息回溯。 --- ### **四、Redis 性能优化** 1. **内存管理** - **淘汰策略**:根据场景选择 `volatile-lru`(淘汰过期 Key 中的最近最少使用)或 `allkeys-lfu`。 - **碎片整理**:启用 `activedefrag yes`(需 Redis 4.0+)。 - **大 Key 拆分**:避免单个 Key 过大(如 Hash 拆分为多个小 Hash)。 2. **网络优化** - **管道(Pipeline)**:合并多个命令一次性发送,减少 RTT(Round-Trip Time)。 - **连接池**:复用连接,避免频繁创建/销毁。 3. **避免阻塞操作** - **禁用长耗命令**:如 `KEYS *` → 改用 `SCAN` 分批次遍历。 - **监控慢查询**:通过 `slowlog get` 分析性能瓶颈。 --- ### **五、Redis 运维与安全** 1. **监控指标** - **内存使用率**:`used_memory` / `maxmemory`。 - **命中率**:`keyspace_hits / (keyspace_hits + keyspace_misses)`。 - **持久化状态**:`rdb_last_save_time`(最后一次 RDB 保存时间)。 2. **安全配置** - **密码认证**:设置 `requirepass` 防止未授权访问。 - **网络隔离**:绑定内网 IP(`bind 127.0.0.1`),禁用危险命令(`rename-command FLUSHDB ""`)。 --- ### **六、Redis 使用建议** 1. **适用场景** - **适合**:高频读、低延迟、数据结构复杂、数据量可控(内存成本高)。 - **不适合**:海量冷数据存储、复杂事务(推荐关系型数据库)。 2. **容量规划** - 预估数据量,预留 20%~30% 内存冗余。 - 使用 `INFO memory` 监控碎片率(`mem_fragmentation_ratio`)。 --- ### **七、Redis vs 其他缓存方案** | 对比项 | Redis | Memcached | |----------------|---------------------------|-------------------------| | **数据结构** | 支持复杂数据结构 | 仅 Key-Value | | **持久化** | 支持 RDB/AOF | 不支持 | | **线程模型** | 单线程(避免锁竞争) | 多线程(CPU 密集型更优) | | **适用场景** | 缓存、消息队列、实时计算 | 纯缓存场景 | --- ### **总结** Redis 通过内存操作和高效数据结构设计,成为解决高并发、低延迟场景的利器使用时需注意: 1. 合理选择数据结构和持久化策略; 2. 避免大 Key 和慢查询; 3. 结合业务场景设计高可用架构(如 Cluster 或 Sentinel)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

少林码僧

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值