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

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

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 条评论
登录 后参与评论

相关文章

来自专栏编程

浅析同步异步阻塞非阻塞

? 先说说这几个词的意思 同步:同步就是一个任务的完成需要依赖另外一个任务时,只有等待被依赖的任务完成后,依赖的任务才能算完成。 异步:异步是不需要等待被依赖...

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

WebSocket协议深入探究

一、内容概览 WebSocket的出现,使得浏览器具备了实时双向通信的能力。本文由浅入深,介绍了WebSocket如何建立连接、交换数据的细节,以及数据帧的格式...

40412
来自专栏java一日一条

分布式系统与消息的投递

消息是一个非常有趣的概念,它是由来源发出一个离散的通信单元,被发送给一个或者一群接受者,无论是单体服务还是分布式系统中都有消息的概念,只是这两种系统中传输消息的...

633
来自专栏即时通讯技术

网络编程懒人入门(四):快速理解TCP和UDP的差异

对于即时通讯开者新手来说,在开始着手编写IM或消息推送系统的代码前,最头疼的问题莫过于到底该选TCP还是UDP作为传输层协议。本文延续《网络编程懒人入门》系列文...

592
来自专栏沈玉琛的专栏

那些年,我们一起误解过的REST

最近几年REST API越来越流行,特别是随着微服务的概念被广泛接受和应用,很多Web Service都使用了REST API。

93914
来自专栏网络

服务化基石之远程通信系列二:通信协议之应用层

通信协议之应用层 应用层包含所有的高层协议,例如FTP (File Transfer Protocol的简写,中文名称是文件传输协议)、SMTP (Simple...

1755
来自专栏即时通讯技术

IM消息送达保证机制实现(二):保证离线消息的可靠投递1、前言 2、学习交流3、IM消息送达保证系列文章4、消息接收方不在线时的典型消息发送流程5、典型离线消息表的设计以及拉取离线消息的过程6、上述流

本文的上篇《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》中,我们讨论了在线实时消息的投递可以通过应用层的确认、发送方的超时重传、接收方的去重等手...

852
来自专栏最高权限比特流

HTTP协议(二):作用

1955
来自专栏前沿技墅

服务化的基石:聊聊通信协议那些事儿

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

计算机网络基础知识笔记(四)

运输层是整个网络体系结构中的关键层次之一。本文讨论TCP/IP体系中运输层最重要的两种协议:TCP/UDP。必须理解TCP的各种机制(面向连接的可靠服务、流量控...

2618

扫描关注云+社区