数据库缓存最终一致性的四种方案

背景

缓存是软件开发中一个非常有用的概念，数据库缓存更是在项目中必然会遇到的场景。而缓存一致性的保证，更是在面试中被反复问到，这里进行一下总结，针对不同的要求，选择恰到好处的一致性方案。

缓存是什么

存储的速度是有区别的。缓存就是把低速存储的结果，临时保存在高速存储的技术。

如图所示，金字塔更上面的存储，可以作为下面存储的缓存。

我们本次的讨论，主要针对数据库缓存场景，将以redis作为mysql的缓存为案例来进行。

为什么需要缓存

存储如mysql通常支持完整的ACID特性，因为可靠性，持久性等因素，性能普遍不高，高并发的查询会给mysql带来压力，造成数据库系统的不稳定。同时也容易产生延迟。

根据局部性原理，80%请求会落到20%的热点数据上，在读多写少场景，增加一层缓存非常有助提升系统吞吐量和健壮性。

存在问题

存储的数据随着时间可能会发生变化，而缓存中的数据就会不一致。具体能容忍的不一致时间，需要具体业务具体分析，但是通常的业务，都需要做到最终一致。

redis作为mysql缓存

通常的开发模式中，都会使用mysql作为存储，而redis作为缓存，加速和保护mysql。但是，当mysql数据更新之后，redis怎么保持同步呢。

强一致性同步成本太高，如果追求强一致，那么没必要用缓存了，直接用mysql即可。通常考虑的，都是最终一致性。

解决方案

方案一

通过key的过期时间，mysql更新时，redis不更新。

这种方式实现简单，但不一致的时间会很长。如果读请求非常频繁，且过期时间比较长，则会产生很多长期的脏数据。

优点：

• 开发成本低，易于实现；
  
• 管理成本低，出问题的概率会比较小。
  

• 完全依赖过期时间，时间太短容易缓存频繁失效，太长容易有长时间更新延迟（不一致）
  

方案二

• 相对方案一，更新延迟更小。
  

• 如果更新mysql成功，更新redis却失败，就退化到了方案一；
  
• 在高并发场景，业务server需要和mysql,redis同时进行连接。这样是损耗双倍的连接资源，容易造成连接数过多的问题。
  

方案三

• 消息队列可以用一个句柄，很多消息队列客户端还支持本地缓存发送，有效解决了方案二连接数过多的问题；
  
• 使用消息队列，实现了逻辑上的解耦；
  
• 消息队列本身具有可靠性，通过手动提交等手段，可以至少一次消费到redis。
  

• 依旧解决不了时序性问题，如果多台业务服务器分别处理针对同一行数据的两条请求，举个栗子，a = 1；a = 5; 如果mysql中是第一条先执行，而进入kafka的顺序是第二条先执行，那么数据就会产生不一致。
  
• 引入了消息队列，同时要增加服务消费消息，成本较高，还有重复消费的风险。
  

方案四

• 在mysql压力不大情况下，延迟较低；
  
• 和业务完全解耦；
  
• 解决了时序性问题。
  

• 要单独搭建一个同步服务，并且引入binlog同步机制，成本较大。
  

总结

方案选型

结论

   
   
   

 
    
    
    

   
   
   

   
   
   



   
   
   

 
    
    
    -END-

   
   
   

   
   
   

 
    
    
    如果看到这里，说明你喜欢这篇文章，请转发、点赞
 
    
    
    。同时标星（置顶）本公众号可以第一时间接受到博文推送。

   
   
   

   
   
   

 
    
    
    推荐阅读

   
   
   

   
   
   

 
    
    
    1. 基友说：“自己整一个”

   
   
   

   
   
   

 
    
    
    2. HashMap为什么线程不安全？

   
   
   

   
   
   

 
    
    
    3. 一致性Hash在负载均衡中的应用

   
   
   

   
   
   

 
    
    
    4. 60个相见恨晚的神器工具