缓存服务的更新策略有哪些?

在互联网项目开发中,缓存的应用是非常普遍了,缓存可以帮助页面提高加载速度,减少服务器或数据源的负载。

1、为什么需要缓存?

一般在项目中,最消耗性能的地方就是后端服务的数据库了。而数据库的读写频率常常都是不均匀分布的,大多情况是读多写少,并且读操作(select)还会有一些复杂的判断条件,比如 like、group、join 等等,这些语法是非常消耗性能的,所有会出现很多的慢查询,因此数据库很容易在读操作的环节遇到瓶颈。

那么通过在数据库前面,前置一个缓存服务,就可以有效的吸收不均匀的请求,抵挡流量波峰。

另外,如果应用与数据源不在同一个服务器的情况下,中间还会有很多的网络消耗,也会对应用的响应速度有很大影响,如果当前应用对数据实时性的要求不那么强的话,在应用侧加上缓存就能很快速的提升效率。

2、那使用缓存会遇到哪些问题呢?

虽然缓存可以提高整体性能,但是它也可能会带来别的问题。例如使用缓存之后,就相当于把数据存放了2份,一份是在数据库中,另一份存放在缓存中。当有新的数据要写入或者旧数据需要更新的时候,如果我们只更新了其中一份数据源,那两边的数据就不一致了,所以这里就存在一个缓存数据与数据库数据如何进行有效且快速的同步问题,才可以保证数据的最终一致性。

另外,加上缓存服务其实也引入了系统架构的复杂度,因为还需要额外的关注缓存自身带来的下列问题:

  1. 缓存的过期时间问题: 设计缓存的过期时间需要非常的有技巧,且必须与业务实际情况相结合。因为如果设计的过期时间太短了,那会导致缓存效果不佳,且还会造成频繁的从数据库中往缓存里写数据。如果缓存设计的过期时间太长了,又会导致内存的浪费。
  2. 缓存的命中率问题: 这也是设计缓存中需要存放哪些数据的很重要一点,如果设计的不好,可能会导致缓存命中率过低,失去缓存效果。一般对于热点数据而言,要保证命中率达到70%以上效果最佳。
  3. 缓存的穿透/雪崩问题: 是指如果缓存服务一旦宕机或全部丢失,那么有可能一瞬间所有的流量都直接打到了后端数据库上,可能会造成连锁反应,瞬间的请求高峰极有可能导致数据库无法承载。

3、缓存的更新策略具体有哪些?

典型的缓存模式,一般有如下几种:

  • Cache Aside
  • Read/Write Through
  • Write Behind

每种模式都有不同的特点,适应与不同的项目场景,下面来依次看看:

  1. Cache Aside 模式

这是大家经常用到的一种策略模式。这种模式主要流程如下:

  • 应用在查询数据的时候,先从缓存Cache中读取数据,如果缓存中没有,则再从数据库中读取数据,得到数据库的数据之后,将这个数据也放到缓存Cache中。
  • 如果应用要更新某个数据,也是先去更新数据库中的数据,更新完成之后,则通过指令让缓存Cache中的数据失效。

这里为什么不让更新操作在写完数据库之后,紧接着去把缓存Cache中的数据也修改了呢?

主要是因为这样做的话,就有2个写操作的事件了,担心在并发的情况下会导致脏数据,举个例子: 假如同时有2个请求,请求A和请求B,并发的执行。请求A是要去读数据,请求B是要去更新数据。初始状态缓存中是没有数据的,当请求A读到数据之后,准备往回写的时候,此刻,请求B正好要更新数据,更新完了数据库之后,又去把缓存更新了,那请求A再往缓存中写的就是旧数据了,属于脏数据。

那么 Cache Aside 模式就没有脏数据问题了吗?不是的,在极端情况下也可能会产生脏数据,比如:

假如同时有2个请求,请求A和请求B,并发的执行。请求A是要去读数据,请求B是要去写数据。假如初始状态缓存中没有这个数据,那请求A发现缓存中没有数据,就会去数据库中读数据,读到了数据准备写回缓存中,就在这个时候,请求B是要去写数据的,请求B在写完数据库的数据之后,又去设置了缓存失效。这个时候,请求A由于在数据库中读到了之前的旧数据,开始往缓存中写数据了,此时写进入的就也是旧数据。那么最终就会导致,缓存中的数据与数据库的数据不一致,造成了脏数据。

不过这种概率比上面一种概率要小很多。所以整体而言 Cache Aside 模式 还是一种比较简单实用的方式。

  1. Read/Write Through 模式

这个模式其实就是将 缓存服务 作为主要的存储,应用的所有读写请求都是直接与缓存服务打交道,而不管最后端的数据库了,数据库的数据由缓存服务来维护和更新。不过缓存中数据变更的时候是同步去更新数据库的,在应用的眼中只有缓存服务。

流程就相当简单了:

  • 应用要读数据和更新数据都直接访问缓存服务
  • 缓存服务同步的将数据更新到数据库

这个模式出现脏数据的概率就比较低,但是就强依赖缓存了,对缓存服务的稳定性有较大要求,另外,增加新缓存节点时还会有初始状态空数据问题。

  1. Write Behind 模式

这个模式就是 Read/Write Through 模式 的一个变种。区别就是 Read/Write Through 模式的缓存写数据库的时候是同步的,而 Write Behind 模式 的缓存操作数据库是异步的。

流程如下:

  • 应用要读数据和更新数据都直接访问缓存服务
  • 缓存服务异步的将数据更新到数据库(通过异步任务)

这个模式的特点就是速度很快,效率会非常高,但是数据的一致性比较差,还可能会有数据的丢失情况,实现逻辑也较为复杂。

以上就是目前三种主流的缓存更新策略,另外还有Refrsh-Ahead模式等由于使用的不是很常见就不详细介绍了。

缓存是互联网项目中非常普遍的一个提高效率的方案,用法比较多,也比较关键,大家可以一起交流。

本文原创发布于微信公众号「 不止思考 」,欢迎关注,交流互联网认知、项目管理、大数据、Web、区块链技术。

原文发布于微信公众号 - 不止思考(bzsikao)

原文发表时间:2018-08-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Golang语言社区

大型服务端开发的反模式技巧

1. 用线程池执行异步任务 ? 为了减少阻塞时间,加快响应速度,把无需返回结果的操作变成异步任务,用线程池来执行,这是提高性能的一种手段。 你可能要惊讶了,这么...

3345
来自专栏Linyb极客之路

Web应用高并发处理方案

1,更多的静态资源:将代码中的大量枚举(容器加载时写入map,放入本地缓存),数据库中的定义表(定时任务放入缓存),固定配置,HTML文件等静态化处理,缓存起来...

872
来自专栏CSDN技术头条

干货丨Tachyon:Spark生态系统中的分布式内存文件系统

Tachyon是Spark生态系统内快速崛起的一个新项目。本质上,Tachyon是个分布式的内存文件系统,它在减轻Spark内存压力的同时,也赋予了Spark内...

1945
来自专栏测试开发架构之路

【转载】Impala和Hive的区别

Impala是基于Hive的大数据实时分析查询引擎,直接使用Hive的元数据库Metadata,意味着impala元数据都存储在Hive的metastore中...

742
来自专栏Golang语言社区

大型服务端开发的反模式技巧

1. 用线程池执行异步任务 ? 为了减少阻塞时间,加快响应速度,把无需返回结果的操作变成异步任务,用线程池来执行,这是提高性能的一种手段。 你可能要惊讶了,这么...

2966
来自专栏Albert陈凯

CAP原则

CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition toleran...

3155
来自专栏CSDN技术头条

Apache Ignite——新一代数据库缓存系统

【编者按】飞速增长的数据需要大量存储,对这些数据的管理也不是一件容易的事。但相比于存储和管理,如何处理数据才是开发人员真正的挑战。对于TB级别数据的存储和处理通...

2199
来自专栏Java学习123

负载均衡设计

3356
来自专栏Ribbon

Spring Cloud 系列-Ribbon

负载均衡(Load Balance): 建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高...

101
来自专栏IT技术精选文摘

分布式系统一致性保障方案总结

引言 在互联网系统中,理想的情况下,肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好,还是BASE理论, 我们知...

25310

扫码关注云+社区