从SpringBoot构建十万博文聊聊缓存穿透,并发量过大该如何抗压?

存储 存储软件
在博客系统中,为了提升响应速度,加入了 Redis 缓存,把文章主键 ID 作为 key 值去缓存查询,如果不存在对应的 value,就去数据库中查找 。这个时候,如果请求的并发量很大,就会对后端的数据库服务造成很大的压力。

 前言

在博客系统中,为了提升响应速度,加入了 Redis 缓存,把文章主键 ID 作为 key 值去缓存查询,如果不存在对应的 value,就去数据库中查找 。这个时候,如果请求的并发量很大,就会对后端的数据库服务造成很大的压力。

[[313074]]

造成原因

  • 业务自身代码或数据出现问题
  • 恶意攻击、爬虫造成大量空的命中,会对数据库造成很大压力

案例分析

由于文章的地址是这样子的:

https://blog.52itstyle.top/49.html

大家很容易猜出,是不是还有 50、51、52 甚至是十万+?如果是正儿八经的爬虫,可能会读取你的总页数。但是有些不正经的爬虫或者人,还真以为你有十万+博文,然后就写了这么一个脚本。

  1. for num in range(1,1000000): 
  2.  //爬死你,开100个线程 

解决方案

设置布隆过滤器,预先将所有文章的主键 ID 哈希到一个足够大的 BitMap 中,每次请求都会经过 BitMap 的拦截,如果 Key 不存在,直接返回异常。这样就避免了对 Redis 缓存以及底层数据库的查询压力。

这里我们使用谷歌开源的第三方工具类来实现:

  1. <dependency> 
  2.  <groupId>com.google.guava</groupId> 
  3.  <artifactId>guava</artifactId> 
  4.  <version>25.1-jre</version> 
  5. </dependency> 

编写布隆过滤器:

  1. /** 
  2.  * 布隆缓存过滤器 
  3.  */ 
  4. @Component 
  5. public class BloomCacheFilter { 
  6.  public static BloomFilter<Integer> bloomFilter = null
  7.  @Autowired 
  8.  private DynamicQuery dynamicQuery; 
  9.  /** 
  10.  * 初始化 
  11.  */ 
  12.  @PostConstruct 
  13.  public void init(){ 
  14.  String nativeSql = "SELECT id FROM blog"
  15.  List<Object> list = dynamicQuery.query(nativeSql,new Object[]{}); 
  16.  bloomFilter = BloomFilter.create(Funnels.integerFunnel(), list.size()); 
  17.  list.forEach(blog ->bloomFilter.put(Integer.parseInt(blog.toString()))); 
  18.  } 
  19.  /** 
  20.  * 判断key是否存在 
  21.  * @param key 
  22.  * @return 
  23.  */ 
  24.  public static boolean mightContain(long key){ 
  25.  return bloomFilter.mightContain((int)key); 
  26.  } 

然后,每一次查询之前做一次 Key 值校验:

  1. /** 
  2.  * 博文 
  3.  */ 
  4. @RequestMapping("{id}.shtml"
  5. public String page(@PathVariable("id") Long id, ModelMap model) { 
  6.  if(BloomCacheFilter.mightContain(id)){ 
  7.  Blog blog = blogService.getById(id); 
  8.  model.addAttribute("blog",blog); 
  9.  return "article"
  10.  }else
  11.  return "error"
  12.  } 

效率

那么,在数据量很大的情况下,效率如何呢?我们来做个实验,以 100W 为基数。

  1. public static void main(String[] args) { 
  2.  int capacity = 1000000; 
  3.  int key = 6666; 
  4.  BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), capacity); 
  5.  for (int i = 0; i < capacity; i++) { 
  6.  bloomFilter.put(i); 
  7.  } 
  8.  /**返回计算机最精确的时间,单位纳妙 */ 
  9.  long start = System.nanoTime(); 
  10.  if (bloomFilter.mightContain(key)) { 
  11.  System.out.println("成功过滤到" + key); 
  12.  } 
  13.  long end = System.nanoTime(); 
  14.  System.out.println("布隆过滤器消耗时间:" + (end - start)); 

布隆过滤器消耗时间:281299,约等于 0.28 毫秒,匹配速度是不是很快?

错判率

万事万物都有所均衡,既然效率如此之高,肯定其它方面定有所牺牲,通过测试我们发现,过滤器有 3% 的错判率,也就是说,本来没有的文章,有可能通过校验被访问到,然后报错!

  1. public static void main(String[] args) { 
  2.  int capacity = 1000000; 
  3.  BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), capacity); 
  4.  for (int i = 0; i < capacity; i++) { 
  5.  bloomFilter.put(i); 
  6.  } 
  7.  int sum = 0; 
  8.  for (int i = capacity + 20000; i < capacity + 30000; i++) { 
  9.  if (bloomFilter.mightContain(i)) { 
  10.  sum ++; 
  11.  } 
  12.  } 
  13.  //0.03 
  14.  DecimalFormat df=new DecimalFormat("0.00");//设置保留位数 
  15.  System.out.println("错判率为:" + df.format((float)sum/10000)); 

通过源码阅读,发现 3% 的错判率是系统写死的。

  1. public static <T> BloomFilter<T> create(Funnel<? super T> funnel, long expectedInsertions) { 
  2.  return create(funnel, expectedInsertions, 0.03D); 

当然我们也可以通过传参,降低错判率。测试了一下,查询速度稍微有一丢丢降低,但也只是零点几毫秒级的而已。

  1. BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), capacity,0.01); 

那么如何做到零错判率呢?答案是不可能的,布隆过滤器,错判率必须大于零。为了保证文章 100% 的访问率,正常情况下,我们可以关闭布隆校验,只有才突发情况下开启。比如,可以通过阿里的动态参数配置 Nacos 实现。

  1. @NacosValue(value = "${bloomCache:false}", autoRefreshed = true
  2. private boolean bloomCache; 
  3. //省略部分代码 
  4. if(bloomCache||BloomCacheFilter.mightContain(id)){ 
  5.  Blog blog = blogService.getById(id); 
  6.  model.addAttribute("blog",blog); 
  7.  return "article"
  8. }else
  9.  return "error"

小结

缓存穿透大多数情况下都是恶意攻击导致的空命中率。虽然十万博客还没有被百度收录,每天也就寥寥的几十个IP,但是梦想还是有的,万一实现了呢?所以,还是要做好准备的!

 

责任编辑:武晓燕 来源: 今日头条
相关推荐

2024-03-27 14:39:48

MySQL数据库分库分表

2017-12-27 12:01:39

2018-12-13 12:43:07

Redis缓存穿透

2023-07-19 07:51:43

Redis缓存高可用

2016-11-28 09:00:10

浏览器浏览器缓存服务端

2009-11-25 13:38:20

IIS并发数

2019-07-21 09:17:11

数据缓存架构

2023-03-10 13:33:00

缓存穿透缓存击穿缓存雪崩

2019-10-12 14:19:05

Redis数据库缓存

2022-06-17 07:49:14

缓存LRU

2019-11-05 14:24:31

缓存雪崩框架

2021-09-06 11:58:24

Python脚本Jmeter

2022-06-12 06:45:26

高并发防重

2020-12-28 12:37:36

缓存击穿穿透

2023-03-07 08:17:19

Postgresql数据库优化

2021-06-05 09:01:01

Redis缓存雪崩缓存穿透

2023-10-04 19:43:38

2021-03-12 18:25:09

开发前端React

2019-12-11 10:14:23

Kafka吞吐量架构

2018-06-19 09:35:51

分布式系统限流
点赞
收藏

51CTO技术栈公众号