Redis缓存!

素颜马尾好姑娘i 2023-10-14 21:09 11阅读 0赞

## 一些基础芝士 ##

将MySQL的热点数据存储在Redis中，通常业务都满足二八原则，80%的流量在20%的热点数据之上，所以缓存是可以很大程度提升系统的吞吐量。  
一般而言， 缓存分为服务器端缓存，和客户端缓存

服务器端缓存即服务端将数据存入Redis，可以在访问DB之后，将数据缓存，或者在回包时将回包内容以请求参数为Key缓存.

(啊 那就每次查询数据之前 看看这个请求有没有加入过 如果有就直接取它的value 发过去)  
客户端缓存就是对服务端远程调用之后，将结果存储在客户端，这样下次请求相同数据时就能直接拿到结果，不会再远程调用，提高性能节省网络带宽。

##    缓存的几种模式 ##

缓存一般有如下几种模式:  
●Cache-Aside Pattern:旁路缓存模式  
Read Through Cache Pattern:读穿透模式  
●Write Through Cache Pattern: 写穿透模式  
●Write Behind Pattern:又叫Write Back，异步缓存写入模式

### 旁路缓存模式 ###

Cache Aside，即旁路缓存模式，是最常见的模式，应用服务把缓存当作数据库的旁路，直接和缓存进行交互。  
读操作的流程如下:  
应用服务收到查询请求后，先查询数据是否在缓存上,如果在，就用缓存数据直接打包返回，如果不存在，就去访问数据库，从数据库查询，并放到缓存中，除了查库后加载这种模式，如果业务有需要，还可以预加载数据到缓存

![41f0a8532cbc43b79321441c3c066ab7.png][]

那它怎么写呢?

![81b80e90a02946ac88762e575860e705.png][]

这里选择的方式是 直接删除 然后下次查询到该数据的时候 再把新的数据缓存了

为啥不直接更新呢

因为更新相比删除会更容易造成时序性问题举个例子:  
thread1更新mysq|为5 -> thread2更 新mysql为3 -> thread2更新缓存为3 -> thread1更新缓存为5，最终正确的数据因为时序性被覆盖了。  
Cache Aside适用于读多写少的场景，比如用户信息、新闻报道等，一旦写入缓存，几乎不会进行修改。该模式的缺点是可能会出现缓存和数据库不一致的情况。

### Read Through    ###

Read-Through,读穿透模式，和Cache Aside模式的区别主要在于应用服务不再和缓存直接交互，而是直接访问数据服务，这个数据服务可以理解为一个代理，即单独起这么一个服务,由它来访问数据库和缓存，作为使用者来看，不知道里面到底有没有缓存，数据服务会自己来根据情况查询缓存或者数据库。  
查询的时候，和Cache Aside一样，也是缓存中有，就用从缓存中获得的数据，没有就查DB，只不过这些由数据服务托管保存，而对应用服务是透明的。  
相比Cache Aside, Read Through的优势是缓存对业务透明，业务代码更简洁。缺点是缓存命中时性能不如CacheAside,相比直接访问缓存，还会多一次服务间调用。  
![ec0c8360319f4e31a378262655086e0c.png][]

套了层壳子罢

### Write Through    ###

在Cache Aside中， 应用程序需要维护两个数据存储:一个缓存，一个数据库。这对于应用程序来说，更新操作比较麻烦，还要先更新数据库, 再去删除缓存。  
WriteThrough模式相当于做了一层封装:  
由这个存储服务先写入MySQL，再同步写入Redis,这样及时加载或更新了缓存数据。可以理解为，应用程序只有一个单独的访问源，而存储服务自己维护访问逻辑。

![1fd131a57fab47f7970ddbffdaf62906.png][]

这个不是之前的读穿透模式那样了 读穿透模式是旁路缓存纯套个壳子 这个写穿透就有改动了

### Write Behind ###

Write-Behind和Write-Through相同点都是写入时候会更新数据库、也会更新缓存。  
不同点在于Write-Through会把数据立即写入数据库中，然后写缓存,安全性很高。而Write-Behind是先写缓存，然后异步把数据一起写入数据库，这个异步写操作是Write-Behind的最大特点。  
数据库写操作可以用不同的方式完成:  
一种是时间上的灵活性，其中一个方式就是收集写操作并在某一时间点(比如数据库负载低的时候)慢慢写入。另一种方式就是合并几个写操作成为一个批量操作，一起批量写入。  
两者是可以根据业务情况结合的。异步写操作极大地降低了请求延迟并减轻了数据库的负担，但是代价是安全性不够,比如先写入了Redis，更新操作先放在存储服务内存中，但是还没异步写入MySQL之前，存储服务崩溃了，那么数据也就丢失了。

就是一个同步一个异步的区别被

**各有优势，但是Cache-Aside Pattern，旁路缓存模式是最常见，最易用的，在业务开发中，其他模式很少会用到**

## 缓存异常场景 ##

### 缓存穿透 ###

缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求。由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。  
如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。谁正常人反复查这个数据 就是恶意让你穿透的

1.接口层增加校验，如用户鉴权校验，id做基础校验，id< =0的直接拦截;  
2.从缓存取不到的数据， 在数据库中也没有取到，这时也可以将key-value对写为key-null, 缓存有效时间可以设置短点，如30秒(设置太长会导致正常情况也没法使用 如果后来这个真的key加入了 那么也无法使用即使旁路缓存也无法访问)。这样可以防止攻击用户反复用同一个id暴力攻击  
3.布隆过滤器。bloomfilter就类似于一 个hash set, 用于快速判某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。布隆过滤器的关键就在于hash算法和容器大小，

### 缓存击穿 ###

问题背景  
缓存击穿是指**缓存中没有但数据库中有的数据(一般是缓存时间到期)**，这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。  
缓存击穿，一般指是指热键在过期失效的一瞬间，还没来得及重新产生，就有海量数据，直达数据库  
●解决方案  
1.热点数据支持续期，持续访问的数据可以不断续期，避免因为过期失效而被击穿  
2.发现缓存失效，重建缓存加互斥锁，当线程查询缓存发现缓存不存在就会尝试加锁，线程争抢锁，拿到锁的线程就会进行查询数据库，然后重建缓存,争抢锁失败的线程，你可以加一个睡眠然后循环重试

### 缓存雪崩 ###

●问题背景  
缓存雪崩顾名思义，是指大量的应用请求因为异常无法在Redis缓存中进行处理，像雪崩一样，直接打到数据库。  
这里异常的原因，也可以说雪崩的原因，主要是:缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至宕机其实在一些资料里，会把Redis宕机算进来,原因是Redis宕机了也就无法处理缓存请求，但这里会觉得有些牵强，如果这里能算，缓存击穿不也可以算?所以这里建议是不把宕机考虑到雪崩里去。

●解决方案  
1.缓存数据的过期时间设置随机，防止同- -时间大量数据过期现象发生。  
2.重建缓存加互斥锁，当线程拿到缓存发现缓存不存在就会尝试加锁，线程争抢锁，拿到锁的线程就会进行查询  
数据库，然后重建缓存，争拾锁失败的线程，你可以加一个睡眠然后循环重试

区分一下 这个击穿是 一条热点数据过期 然后大量请求去查询这个热点数据 然后雪崩是大量的数据过期 这个大量的请求去请求这些数据

## 缓存一致性问题 ##

缓存，都知道是持久化数据的冗余存储，但如果缓存加载了数据源的数据，但对应数据要发生变化，怎么办呢?  
我们以数据源为MySQL，缓存用Redis，前面也说过了,在数据库场景下，更廉价、高效但可靠性稍低的redis可以给更昂贵、较慢、可靠性强的mysq|做缓存。  
前面介绍了几种缓存模式，这里我们以常见、最实用的旁路缓存模式为基础，来进行分析。  
大的方向有三:  
1.更新MySQL即可，不管Redis,以过期时间兜底  
2.更新MySQL之后,操作Redis  
3.异步将MySQL的更新同步到Redis

### 方向一 ###

使用redis的过期时间，mysqI更新时，redis不做处理，等待缓存过期失效，再从mysq|拉取缓存。  
这种方式实现简单，但不一致的时间会比较明显，具体由你的业务来配置。如果读请求非常频繁,且过期时间设置较长，则会产生很多脏数据。  
优点:  
redis原生接口，开发成本低，易于实现;  
管理成本低，出问题的概率会比较小。  
不足:  
完全依赖过期时间,时间太短容易造成缓存频繁失效，太长容易有较长时间不一 致

### 方向二 ###

不光通过key的过期时间兜底，还需要在更新mysql时，同时尝试操作redis,这里的操作分两种方式，1是更新，直接将结果写入Redis，但实际上很少用更新，而是用删除，等待下次访问再加载回来，为什么呢?因为更新容易带来时序性问题。  
举个例子:假设a的初始值为2,两台业务服务器在同一时间发出两条请 求:  
第一条,给a的值加1  
第二条,设置a的值为5  
若mysqI中先执行第一条， 再执行第二条,则mysq|中a的值先变成3，最终为5;  
但由于网络传输本身有延迟,所以无法保证两条Redis更新操作谁先执行，如果第二条对应的更新先执行，Redis的数据就先变成了5，然后在加1变成了6。  
这就出现数据对不上的问题，相比于数据延迟而言，这更让人疑惑和不能接受。所以一般都选择 删除。  
上面有提到，这里是尝试删除，这样说是这一步操作是可能失败了，**失败就我们可以忽略**，也就是不能让删除成为一个关键路径，影响核心流程。  
**因为我们有key本身的过期时间作为保障，所以最终一致性是一 定达成的， 主动删除redis数据只是为了减少不一致的时间。**  
优点:  
相对方案一，达成最终一致性的延迟更 小;  
实现成本较低， 只是在方案-的基础上， 增加了删除逻辑。  
不足:  
如果更新mysql成功，删除redis却失败，就退化到了方案- - ;  
在更新时候需要额外操作Redis，带来了损耗。

### 方向三 ###

把我们搭建的消费服务作为mysqI的一个slave,订阅mysqI的binlog日志，解析日志内容，再更新到redis.此方案和业务完全解耦，redis的更新对业务方透明，可以减少心智成本。

优点:  
和业务完全解耦，在更新mysq|时,不需要做额外操作;  
无时序性问题，可靠性强。  
缺点:  
引入了消息队列这种算比较重的组件，还要单独搭建一个同步服务.维护他们是非常大的额外成本  
同步服务如果压力比较大，或者崩溃了，那么在较长时间内，redis中都是老旧数据

[41f0a8532cbc43b79321441c3c066ab7.png]: https://img-blog.csdnimg.cn/41f0a8532cbc43b79321441c3c066ab7.png
[81b80e90a02946ac88762e575860e705.png]: https://img-blog.csdnimg.cn/81b80e90a02946ac88762e575860e705.png
[ec0c8360319f4e31a378262655086e0c.png]: https://img-blog.csdnimg.cn/ec0c8360319f4e31a378262655086e0c.png
[1fd131a57fab47f7970ddbffdaf62906.png]: https://img-blog.csdnimg.cn/1fd131a57fab47f7970ddbffdaf62906.png