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

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

10年的钟山网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。营销型网站的优势是能够根据用户设备显示端的尺寸不同，自动调整钟山建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联建站从事“钟山网站设计”,“钟山网站推广”以来，每个客户项目都认真落实执行。

1、为什么需要缓存?

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

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

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

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

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

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

• 缓存的过期时间问题：设计缓存的过期时间需要非常的有技巧，且必须与业务实际情况相结合。因为如果设计的过期时间太短了，那会导致缓存效果不佳，且还会造成频繁的从数据库中往缓存里写数据。如果缓存设计的过期时间太长了，又会导致内存的浪费。

• 缓存的命中率问题：这也是设计缓存中需要存放哪些数据的很重要一点，如果设计的不好，可能会导致缓存命中率过低，失去缓存效果。一般对于热点数据而言，要保证命中率达到70%以上效果最佳。

• 缓存的穿透/雪崩问题：是指如果缓存服务一旦宕机或全部丢失，那么有可能一瞬间所有的流量都直接打到了后端数据库上，可能会造成连锁反应，瞬间的请求高峰极有可能导致数据库无法承载。

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

典型的缓存模式，一般有如下几种：

• Cache Aside

• Read/Write Through

• Write Behind

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

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 模式 还是一种比较简单实用的方式。

Read/Write Through 模式

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

流程就相当简单了：

应用要读数据和更新数据都直接访问缓存服务

缓存服务同步的将数据更新到数据库

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

Write Behind 模式

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

流程如下：

应用要读数据和更新数据都直接访问缓存服务

缓存服务异步的将数据更新到数据库(通过异步任务)

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

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

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

本文转自微信公众号：不止思考  作者：奎哥

原文链接：https://mp.weixin.qq.com/s/GhTJ0rbxDrVO_Q5YRcKb0w