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

  

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

  

  <强>   1,为什么需要缓存?      

  

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

  

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

  

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

  

  <强>   2,那使用缓存会遇到哪些问题呢?      

  

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

  

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

     <李>   

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

  李   <李>   

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

  李   <李>   

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

  李      

  <强>   3、缓存的更新策略具体有哪些吗?      

  

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

     <李>   

  除了缓存   

  李   <李>   

  通过读/写   

  李   <李>   

  后面写   

  李      

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

  

  <强>   除了缓存模式      

  

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

  

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

  

  应用在查询数据的时候,先从缓存缓存中读取数据,如果缓存中没有,则再从数据库中读取数据,得到数据库的数据之后,将这个数据也放到缓存缓存中。   

  

  如果应用要更新某个数据,也是先去更新数据库中的数据,更新完成之后,则通过指令让缓缓存中存的数据失效。   

  

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

  

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

  

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

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