分流:到达服务之前,减少服务处理的请求数。
并发:到达服务之后,提升服务处理的请求数。
缓存设计
导流:将原本复杂的操作请求(sql 大堆),引导到简单的请求上。前人栽树后人乘凉。
缓存:空间换时间的一个做法。
redis, memcached,localcache guava,客户端缓存
user_info_xxxx : 姓名,年龄,xxx。getKey 内存操作
select * from user where id = xxx。 硬盘IO
缓存的收益
成本,收益。
读、写。
位置:介于 请求方和提供方之间。
收益:节省了响应时间。
成本:
kv
计算key的时间,查询key的时间,转换值的时间。命中率P。
所有数据的查询时间=计算key的时间+查询key的时间+转换值的时间+(1-p) * 原始查询时间
计算key的时间+查询key的时间+转换值的时间+(1-p) * 原始查询时间 <<<< 所有数据 的原始查询时间
适合:耗时特别长的查询(复杂sql),读多写少。
缓存键的设计
kv
单向函数:给定输入,很容易,很快能计算出结果,但是给你结果,很难计算出输入。
正向快速,逆向困难,输入敏感,冲突避免。
sha-256
冲突的概率 极低。
查询key的速度 取决于:物理位置 (内存,硬盘)。
值:
序列化
对象
总结:
无碰撞。高效生成。高效查询,高效转换。
上面所有:都被中间件提供的api 封装了。
实际中:前缀业务关键信息后缀。 公司统一制定规范。
user_order_xxxx:
user+order+xxxx:
user-order-xxxx:
$
缓存的更新机制
被动更新
调用方 暂存方(缓存) 数据提供方
被动:有效期到后,再次写入。
1。客户端 查数据,缓存中没有,从提供方获取,写入缓存(有一个过期时间t)。
2。在t内,所有的查询,都由缓存提供。所有的写,直接写数据库。
3。当 缓存数据 t 到点了,缓存 数据 变没有。后面的查询,回到了第1步。
适合:对数据准确性和实时性要求不高的场景。比如:商品 关注的人数。
主动更新
主动:被其他操作直接填充。
数据库:更新数据库
缓存:更新缓存,删除缓存
保持一个定量,考虑围绕它的变量,这样才不会有异常的遗漏。
更新缓存,更新数据库
数据不一致的风险比较高,所以一般不采用。
更新数据库,更新缓存
一般也不采用。
请求被阻塞,
业务要求:修改数据库,然后经过大量的计算,才能得出缓存的值。浪费了性能。如果缓存还没用,更浪费。
删除缓存,为了节省计算时间。
删除缓存,更新数据库
一般不采用,因为大概率 读比写快。
延时双删,休眠多久,系统吞吐量下降。
昨天被高德一个面试问:说,你这个延时双删有这么几步操作。如果其中某一步失败了这么办?
删除缓存
更新数据库:事务,回滚就OK。
第二次删除缓存
重试删除:当你前面的操作,无法回滚时,为了保证后续数据的一致性,
(最便宜的做法)硬着头皮往前走,重试。
借用中间件:消息队列,重发消息。
系统外订阅:canal。binlog。
二次删除key,和我们的业务代码解耦。
更新数据库,删除缓存
经常采用的方式。
cache-aside模式。
异常流程:
前提:缓存无数据。数据库有数据。
A:查询,B:更新
A查缓存,无数据,去读数据库,旧值。-----查
B更新数据库 新值
B删除缓存
A 将旧值写入缓存。
脏数据。
就是说这个方案也有问题?这次是读的速度慢了?
读比写慢 概率很低,极低。
缓存无数据。
如果非要解决,延时双删。再删除一次。
Read/Write Through
程序启动时,将数据库 的数据, 放到缓存中,不能等启动完成,再放缓存中。
Write Behind
降低了写操作的时间,提高了系统吞吐量。
双写一致性。
缓存清理机制
如何提升缓存命中率:尽可能多的缓存。所有数据都放缓存,命中率 100%。
我们需要用有限的缓存空间,发挥最大的作用。
如何判断 一个数据 在未来被访问的次数呢?
读的时间频繁:当清理一个数据的时候,发现,它一直被访问,那我就认为他 马上的未来,也会被访问。
写入时间的时间节点。
我是问代码怎么实现:当清理数据时,发现他一直被访问。
读一次,记录一次 ,时间。阈值。
读:
getKey, k =0 ttl 1min , incr
if(!getK > 1){
delete k
}
时效性清理
给缓存设置一个过期时间,到期 缓存 自动 清理。
缓存中的数据 有 一个 生存时间:ttl。过期时间。set k v ex 10 s
set cookie 过期时间。
k v 10s
定时任务轮询。delete
自动清理机制: cookie redis expire .。(本质:轮询)
数目阈值式清理机制
判断缓存中的缓存的数量 达到一定值 ,对缓存进行清理。
阈值:根据自己的业务来定。1g,1m,1024个, 800 80%。
采取什么策略去清理:
fifo: 先进先出
package com.example.cachetest;
import java.util.LinkedList;
import java.util.Queue;
/**
* 数据阈值式清理
*/
public class CacheThresholdTest {
public static void main(String[] args) {
Queue<String> queue = new LinkedList<>();
for (int i = 0; i < 4; i++) {
setCache(queue,""+i);
}
}
public static void setCache(Queue<String> queue,String cache){
int size = queue.size();
if (size >= 3){
queue.poll();
}
queue.add(cache);
System.out.println("缓存中的值如下:");
for (String q: queue) {
System.out.println(q);
}
}
}
random:随机
lru:规律:
LinkedHashMap 套。fifo,lru。
map:存 键值对。
顺序:插入顺序 fifo,访问顺序 lru。
removeEldestEntry。
package com.example.cachetest;
import org.junit.jupiter.api.Test;
import java.util.LinkedHashMap;
import java.util.Map;
public class TestCache {
@Test
public void testLinkedHashMap() {
// 在介绍accessOrder属性的时候说accessOrder设置为false时,按照插入顺序,设置为true时,按照访问顺序
LinkedHashMap<String, String> map = new LinkedHashMap<String, String>(5, 0.75F, true) {
@Override
protected boolean removeEldestEntry(Map.Entry<String, String> eldest) {
//当LinkHashMap的容量大于等于5的时候,再插入就移除旧的元素
return this.size() >= 5;
}
};
map.put("1", "bb");
map.put("2", "dd");
map.put("3", "ff");
map.put("4", "hh");
System.out.println("原始顺序:");
print(map);
map.get("2");
System.out.println("2 最近访问:");
print(map);
map.get("3");
System.out.println("3 最近访问:");
print(map);
map.put("5","oo");
System.out.println("加元素");
print(map);
}
void print(LinkedHashMap<String, String> source) {
source.keySet().iterator().forEachRemaining(System.out::println);
}
}
实现:k v。 map 一台服务器上能用。redis。
软引用清理
用空间换时间的模块。尽量用空间,用以提高缓存 命中率p。
适时的释放空间,gc。
识别出要清理的缓存,然后清除。
gc root引用。
强:哪怕自己oom,不清理。(不用)
软:当空间不足的时候,会被回收。√。
弱
虚
空间不足时,进行缓存清理。软引用。
把值 放到 SoftReference 包装中。
package com.example.cachetest;
import java.lang.ref.ReferenceQueue;
import java.lang.ref.SoftReference;
import java.util.*;
/**
* 软引用 缓存 实验
*/
public class CacheSoftReferenceTest {
public static void main(String[] args) throws InterruptedException {
soft();
}
static void soft(){
// 缓存
Map<Integer, SoftRefedStudent> map = new HashMap<Integer, SoftRefedStudent>();
ReferenceQueue<Student> queue = new ReferenceQueue<Student>();
int i = 0;
while (i < 10000000) {
Student p = new Student();
map.put(i, new SoftRefedStudent(i, p, queue));
//p = null;
SoftRefedStudent pollref = (SoftRefedStudent) queue.poll();
if (pollref != null) {//找出被软引用回收的对象
//以key为标志,从map中移除
System.out.println("回收"+pollref.key);
map.remove(pollref.key);
System.out.println(i+"新一轮================================================");
Iterator<Map.Entry<Integer, SoftRefedStudent>> iterator = map.entrySet().iterator();
while (iterator.hasNext()){
Map.Entry entry = iterator.next();
if ((int)entry.getKey() == pollref.key){
System.out.println("见鬼了");
}
}
System.out.println(i+"新一轮================================================");
}
i++;
}
System.out.println("done");
}
}
class Student{
private String name;
private int age;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getAge() {
return age;
}
public void setAge(int age) {
this.age = age;
}
}
class SoftRefedStudent extends SoftReference<Student> {
public int key;
// 第3个参数叫做ReferenceQueue,是用来存储封装的待回收Reference对象的
/**
* 当Student对象被回收后,SoftRefedStudent对象会被加入到queue中。
*/
public SoftRefedStudent(int key, Student referent, ReferenceQueue<Student> q) {
super(referent, q);
this.key = key;
}
}
缓存清理机制总结
时效式清理+数目阈值:防止:短期内,密集查询,导致缓存空间的急剧增大。
--自己的完整思路。
lru+软引用:保证热数据,最大限度的提高 缓存命中率,p。
不建议:仅仅使用 软引用。因为我们失去了对它的控制。
目的:提高缓存命中率,节省空间,=》提升性能。
缓存风险概述
在系统中,每增加一个环节,就多一份风险。用是不得已。
缓存穿透
缓存中没有,数据库也没有。
方案:在第一次调用的时候,数据提供方返回一个空值,将空值放到缓存中。
缓存雪崩
大量缓存突然失效,导致大量的请求,倾泻到数据库上,引起数据库压力骤增。
时效式清理:批量缓存,统一时间到期。缓存ttl=(固定时间,结合业务)+随机时间。
软引用清理:某个时间点,空间突然紧张,常用的缓存用强引用,不常用的用软引用。
缓存击穿
高频率的缓存,突然失效,大量请求倾泻到数据库上。
lru:
read write through or write behind.更新机制:无所谓。数据永远留在缓存当中。
缓存预热
read write through or write behind
预热:高频访问的,提前准备。
计价规则,提前加载到缓存中。
系统启动前:加载缓存,不让缓存统一时间过期。
电商系统:热门商品,提前加入缓存。网约车中,计价规则提前加入缓存。
热门数据,加到缓存。
缓存风险的总结
遇到风险,分析原因,解决之。
原因:更新机制,清理机制。
标签:map,缓存,数据库,key,println,设计,public From: https://www.cnblogs.com/fylh/p/18037341