【分布式缓存】分布式缓存-缓存技术

最新推荐文章于 2024-08-02 00:56:11 发布

qxlxi

最新推荐文章于 2024-08-02 00:56:11 发布

阅读量6k

点赞数 5

分类专栏： # NoSQL 文章标签：缓存分布式 java

本文链接：https://blog.csdn.net/jia970426/article/details/122550113

版权

NoSQL 专栏收录该内容

21 篇文章 0 订阅

订阅专栏

1. 从数据的使用说起

我们把数据的使用频率和方式分个类

静态数据：一般不变，类似于字典表
准静态数据：变化频率很低，部门结构设置，全国行政区划数据等
中间状态数据：一些计算的可复用中间数据，变量副本，配置中心的本地副本
热数据：使用频率高
读写比较大：读的频率 >> 写的频率
这些数据适合于使用缓存的方式访问

广义上来说，为了加速数据处理，让业务更快访问的临时存放冗余数据，都是缓存狭义上，现在我们一般在分布式系统里把缓存到内存的数据叫做内存缓存还有没有其他数据？

缓存无处不在内存

~ 可以看做是 CPU 和磁盘之间的缓存
CPU与内存的处理速度也不一致，出现 L1&L2 Cache
网络处理，数据库引擎的各种Buffer，都可以看做是缓存
GUI的Double Buffer（双缓冲），是一个经典的性能优化方法

缓存的本质：系统各级处理速度不匹配，导致利用空间换时间
缓存是提升系统性能的一个简单有效的办法

缓存加载时机

1、启动全量加载 ==> 全局有效，使用简单
2、懒加载
同步使用加载 ==>
- 先看缓存是否有数据，没有的话从数据库读取
- 读取的数据，先放到内存，然后返回给调用方
延迟异步加载 ==>
- 从缓存获取数据，不管是否为空直接返回 ==>
- 策略1异步）如果为空，则发起一个异步加载的线程，负责加载数据
- 策略2解耦）异步线程负责维护缓存的数据，定期或根据条件触发更新

缓存的有效性与数据同步

在这里插入图片描述

缓存使用不当导致的问题

1、系统预热导致启动慢试想一下，一个系统启动需要预热半个小时。导致系统不能做到快速应对故障宕机等问题。
2、系统内存资源耗尽只加入数据，不能清理旧数据。旧数据处理不及时，或者不能有效识别无用数据。

2. 本地缓存

最简单的本地缓存

在这里插入图片描述

Hibernate/MyBatis都有Cache

在这里插入图片描述

Guava Cache

在这里插入图片描述

Spring Cache

在这里插入图片描述

3. 远程缓存

考虑一下本地缓存有什么缺点?

1、在多个集群环境同步？当集群规模增大，缓存的读写放大。
2、在JVM中长期占用内存？如果是堆内存，总是会影响GC。
3、缓存数据的调度处理，影响执行业务的线程，抢资源。
== > 集中处理缓存
聪明的你，思考一下：有什么缺点呢?

Redis/Memcached 缓存中间件

REmote DIctionary Server(Redis) 是一个由Salvatore Sanfilippo写的key-value存储系统。Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
Memcached是以LiveJournal旗下Danga Interactive公司的Brad Fitzpatric为首开发的一款开源高性能，分布式内存对象缓存系统。
Redis 官网：https://redis.io/
Redis 在线测试：http://try.redis.io/
Redis 命令参考：http://doc.redisfans.com/
《Redis 设计与实现》：http://redisbook.com/
Memcached 官网：https://memcached.org/

Hazelcast/Ignite 内存网格

4. 缓存策略

容量

资源有限

缓存数据容量是必须要考虑的问题
思考系统的设计容量、使用容量、峰值，应该是我们做架构设计的一个常识

过期策略

按FIFO或LRU - 按固定时间过期
按业务时间加权：例如3+5x

5. 缓存常见问题

缓存穿透

问题：大量并发查询不存在的KEY，导致都直接将压力透传到数据库。
分析：为什么会多次透传呢？不存在一直为空。需要注意让缓存能够区分KEY不存在和查询到一个空值。
解决办法：
1、缓存空值的KEY，这样第一次不存在也会被加载会记录，下次拿到有这个KEY。
2、Bloom过滤或RoaringBitmap 判断KEY是否存在。
3、完全以缓存为准，使用延迟异步加载的策略2，这样就不会触发更新。

缓存击穿

问题：某个KEY失效的时候，正好有大量并发请求访问这个KEY。
分析：跟前面一个其实很像，属于比较偶然的。
解决办法：
1、KEY的更新操作添加全局互斥锁。
2、完全以缓存为准，使用延迟异步加载的策略2，这样就不会触发更新。

缓存雪崩

问题：当某一时刻发生大规模的缓存失效的情况，会有大量的请求进来直接打到数据库，导致数据库压力过大升值宕机。
分析：一般来说，由于更新策略、或者数据热点、缓存服务宕机等原因，可能会导致缓存数据同一个时间点大规模不可用，或者都更新。所以，需要我们的更新策略要在时间上合适，数据要均匀分散，缓存服务器要多台高可用。
解决办法：
1、更新策略在时间上做到比较均匀。
2、使用的热数据尽量分散到不同的机器上。
3、多台机器做主从复制或者多副本，实现高可用。
4、实现熔断限流机制，对系统进行负载能力控制。