reids缓存相关知识

5 篇文章 0 订阅
4 篇文章 0 订阅

分布式缓存

缓存穿透、雪崩、击穿

1、缓存穿透:

缓存穿透是指大量请求访问一个不存在的数据,由于数据库中没有,所以redis不会缓存,导致每次查询都需要访问数据库,造成缓存穿透

解决办法
缓存空值,即使数据库中不存在这个值,也要在redis中缓存起来,防止缓存穿透

2、缓存雪崩

由于大量缓存设置的过期时间相同,在某一时刻,缓存同时过期,造成大量请求访问数据库。

解决办法
每个缓存的过期时间加上一个随机值,保证缓存不会同时过期

3、缓存击穿

某一热点数据的缓存过期,该时刻大量请求访问数据库,造成缓存击穿

解决办法
1、设置二级缓存
2、加锁
加锁可以加本地锁,也可以加分布式锁。如果加本地锁,那么每台服务器都会放行一个请求来访问数据库,这影响并不大,不会有多大的并发量。

分布式锁原理

1、可重入锁Lock

可重入锁是一种自旋锁,没有获取到锁,就自旋,直至获取到锁;并且Lock引入了看门狗机制。

看门狗机制

如果可重入锁没有设置过期时间,就会启用看门狗机制,看门狗机制有两大特点:
1、自动给锁设置过期时间,看门狗机制会自动给锁设置一个30s的过期时间
2、当时间到达到看门狗设置的过期时间的三分之一时,此时业务没有执行完成,看门狗会自动将锁的过期时间重新更新为30s

最佳实战

推荐还是自己给锁设置一个过期时间,这样可以省掉整个续期操作。

//注入redisson
@Autowired
Redission redission;

public ... method1(...){
	RLock lock = redission.getLock("key");
	lock.lock(10,TimeUnit.SECOND);
	try{
		//业务方法
	}catch(Exception e){

	}finally{
		//手动解锁
		lock.unlock();
	}
	
}
public ... method2(...){
	RLock lock = redission.getLock("key");
	//最多等待100秒,如果100秒没有获取到锁,则放弃
	boolean res = lock.tryLock(100,10,TimeUnit.SECOND);
	if(res){
		try{
		//业务方法
		}catch(Exception e){

		}finally{
			//手动解锁
			lock.unlock();
		}
	}
	
	
	
}
2、读写锁

读锁是一种共享锁,写锁是排他锁,他们组合一共4种情况

读+读:相当于无锁,是一种并发存在,他们会同时加锁成功
读+写:写锁要等待读锁完成才能继续
写+写:阻塞状态
写+读:读锁等待写锁成功才能获取锁

RReadWriteLock lock = redission.getReadLockWrite("key");
lock.getReadLock();
lock.getWriteLock();
3、信号量

只有规定数目的请求能获取到信号量锁,其他请求需等待获取锁的请求执行完毕之后才能获取到锁。

//需要先在数据库中设置能获取到锁的请求的数量
//key:name,value:锁的数量
RSemaphore lock = redission.getSemafore("name");
//获取锁,acquire,tryAcquire,acquire会阻塞等待,tryAcquire返回布尔值,不会等待
lock.acquire();
lock.tryAcquire();
//锁释放
lock.release();
4、闭锁

执行完指定数量的请求之后,才会执行闭锁代码
举例:学校要等所有班级(请求数量)的同学都走完之后,才能锁大门(闭锁方法)

//执行关门方法
public ... closeMethod(...){
	RCountDownLatch latch = redission.getCountDownLatch("name");
	latch.trySetCount(5)//有几个班级
	//只有等所有班级都走人之后才能继续执行
	latch.await()
	//业务方法
}

//班级走人
public ... letsGo(...){
	RCountDownLatch latch = redission.getCountDownLatch("name");
	//业务方法
	latch.countDown();
}



缓存一致性

保证缓存一致性有两种模式,分别是双写模式和失效模式

1、双写模式

在修改数据库的同时将修改后的数据写入缓存中

可能出现的问题

缓存不一致
出现这种情况,可以给缓存设置一个生效时间来解决,在缓存过期后,重新读取数据库,并写入缓存,此时就达到了数据一致。这是最终一致性,不是强一致,主要看业务能容忍的缓存不一致的时间是多少

2、失效模式

写入数据库之后,使缓存失效
在这里插入图片描述

总结:

无论是双写模式,还是失效模式,都有可能造成数据最后一次更新,没有映射到缓存上
放入缓存中的数据,本身一致性就要求没那么强,如果要求强一致性,则直接查询数据库

解决办法

使用读写锁,并且给缓存加上一个过期时间,达到数据的最终一致性

SpringCache

-----------------------------------未完待续-----------------------------------------------------

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值