美文网首页Java 程序员Java
架构师成长之路:高层架构设计中如何确定缓存架构

架构师成长之路:高层架构设计中如何确定缓存架构

作者: 程序花生 | 来源:发表于2021-10-09 13:47 被阅读0次

前面已经把用于功能开发的 整体技术架构 基本搭建好了,感觉已经可以落地使用了。

但是,仍然会有很多没有考虑全面的地方,比如缓存和异步消息的架构, 这两个基本上是 目前 做实际应用的标配了,因此在高层架构设计阶段, 同样要对这样通用的、或者是公共的架构进行架构设计。

我们先来聊一聊如何确定缓存架构的话题。

大家都知道,合理使用缓存能大大提升应用的性能,因此设计合理的缓存架构就是架构设计当中一个非常重要的内容了。

一:考虑缓存分级,也就是多级缓存

简单点说,就是把缓存分成很多个层级,基本上是数据从发出开始,经过的所有环节,都有可能做缓存。常见的有:

  1. 浏览器缓存:
    前端缓存,这个不多说

  2. CDN缓存:
    这个是花钱买的服务,也不多说

  3. 负载均衡缓存:
    比如Nginx的缓存,可以把一些较少变化的数据,放到Nginx缓存中
    也可以在Nginx里面,直接使用插件,去直接访问缓存中的数据,这样就无须调用后面的应用服务。

  4. 进程内缓存:
    对Java而言,就是JVM缓存

  5. 分布式缓存:
    比如使用redis,存放共享的session信息、权限信息等

这里是高层架构设计阶段,主要还是制定整体的架构形式,因此比较粗略,并不会深入具体的业务,也不会去过多的关注具体如何使用缓存的一些细节,比如:具体使用什么数据类型、存储数据的格式等等,那些具体的设计,放到概要设计或者是详细设计阶段再去完成。

二:确定基本的缓存技术方案

这里除了要决策在哪些地方使用缓存,另外要确定下来 具体要使用的缓存框架,比如:使用Redis、ElasticSearch、MongoDB、内存数据库等等。

具体的方案要结合着具体的应用来思考,这里只是举例,不是说每个项目都是这样来做缓存,这一点大家要注意。比如:

  • 对于热点数据,使用Nginx本地缓存
  • 对于使用特别频繁的数据,考虑使用JVM缓存
  • 对于实体类的缓存数据,使用ElasticSearch,特别擅长按条件查找数据

其它缓存数据使用Redis,比如:幂等控制数据,类似于分布式锁,当然这个也可以使用Zookeeper来实现; session共享数据 ;登录控制数据 等等

到这里我们就基本确定下来,缓存的技术方案,要使用几级缓存,大概每一级用什么样的技术去做。

三:需思考的点

实际应用中,需要思考的地方很多,这里讲几个常见的:

1:缓存拆分

就是要思考,是否需要拆分?

比如:用户数据、产品数据、订单数据、登录session等,是放在一个Redis里面,还是需要进行拆分,放到不同的Redis里面去。

这个又涉及很多,要去估算业务量,估算数据量的大小,估计访问Redis的频率,估计读写的比例、并发访问量等等的。

如果拆分,该如何拆分?

通常就是做横向和纵向的拆分,类似于数据库的 分库分表 ,也就是所谓的纬度化缓存。

2:缓存持久化

是否需要持久化?如何持久化?

比如对Redis:AOF、RDB

3:集群

是否需要集群?

ElasticSearch是天生支持集群,对于Redis,就要考虑是只采用主从复制,还是真的需要做集群,集群又要考虑是做哨兵集群,还是采用redis cluster来做集群。

以及集群的形式、集群方案、分片键的选择(这个可以放到后面的概要或者详细设计中去)等

4:常见问题:

需要为失败而设计,准备好相应的处理方案

(1)雪崩

其实就是请求缓存的数据在缓存中不存在,这样大量的请求最后都落到了数据库上,从而造成数据库压力大,甚至无法访问的情况。

至于为啥缓存中没有对应的缓存数据,有可能是还没有加载到缓存中来,也有可能是因为缓存过期被清除,或者是缓存节点故障等。

对于这个问题,我们要合理的设计缓存数据的方案,哪些数据放入缓存、什么时候放入缓存、是否过期、什么时候过期、超时时间是多少 等等。

另外:也要准备一些Plan B,比如:

  • 限流:当缓存服务无法支持高并发的时候,可以把无法响应的请求放入到请求队列或者是直接返回。
  • 隔离:当缓存无法提供服务的时候,把请求放入队列中,这样可以实现请求隔离,避免这个请求被路由到其它缓存节点,从而导致其他缓存节点故障。
(2)穿透

缓存一般是 Key,Value 方式存在,一个 Key 对应的 Value 不存在时,请求会回源到数据库。

假如对应的 Value 一直不存在,则会频繁的请求数据库,对数据库造成访问压力。

解决方法:

第一种是缓存层缓存空值

将数据库中的空值也缓存到缓存层中,这样查询该空值就不会再访问DB,而是直接在缓存层访问就行。

但是这样有个弊端就是缓存太多空值占用了更多的空间,可以通过给缓存层空值设立一个较短的过期时间来解决,例如60s。

第二种是布隆过滤器

将数据库中所有的查询条件,放入布隆过滤器中,

当一个查询请求过来时,先经过布隆过滤器进行查,如果判断请求查询值存在,则继续查;如果判断请求查询不存在,直接丢弃。

(3)缓存击穿

在数据请求的时候,某一个缓存刚好失效或者正在写入缓存,同时这个缓存数据可能会在这个时间点被超高并发请求,成为“热点”数据。

这就是缓存击穿问题,这个和缓存雪崩的区别在于,这里是针对某一个缓存,前者是针对多个缓存。

解决方案:导致问题的原因是在同一时间读/写缓存,所以只有保证同一时间只有一个线程写,写完成以后,其他的请求再使用缓存就可以了,比较常用的做法是使用 mutex(互斥锁)。

在高层架构设计中,确定缓存架构的话题,就先聊到这里。

至于还有很多其他缓存使用上的一些细节,留到后面概要设计和详细设计阶段再设计,比如:

  • 提高缓存命中率
  • 缓存和数据库双写不一致问题
  • 如何分片
  • 热点问题
  • 如何写缓存
  • 如何更新缓存?增量?全量?
  • 数据如何被移除
  • 过期的策略
  • 数据如何恢复
  • 数据如何迁移
  • 如何预热
  • 如何冷启动
  • ……

作者:CTO说
链接:https://www.toutiao.com/a7011375616826081828/?log_from=cf0e77036eecd_1633757721280

相关文章

网友评论

    本文标题:架构师成长之路:高层架构设计中如何确定缓存架构

    本文链接:https://www.haomeiwen.com/subject/edsqoltx.html