面试高频db-缓存数据一致性问题

面试中经常被问到怎么较少对并发对mysql的冲击，最好最简单的就是缓存，例如redis

那么redis和mysql的数据一致性怎么保证呢？

首先 我们来看下一致性的概念，强一致性：要求写入和读取的数据时刻保持一致，此种对系统的性能影响最大弱一致性：数据写入和读取的数据允许存在差别忙也不要求差别的时间要求，但是尽可能的在某个时刻达到一致性最终一致性：是弱一致性的特例，系统保证在一定时间内达到数据的一致性

今天我们来看下几种缓存模式Cache-Aside Pattern 旁路缓存策略Read-Through/Write throughWrite behind

1、 Cache-Aside Pattern 旁路缓存策略

尽可能的保证缓存和数据库的数据一致

主要流程

主要流程

读请求->缓存->未命中->读取数据库->更新缓存->返回

写请求 ->更新数据库->删除缓存

这里有个疑问，cache-aside模式在写入的时候为什么是删除而不是更新呢？

我们看个场景1、sessionA 发起一个写请求，第一步更新了数据库2、sessionB发起一个写请求，第二步更新了数据库3、sessionB更新了缓存4、sessionA由于网路延迟，在sessionB之后更新了缓存

此时，就是缓存中的数据不是最新的，如果删除操作的话就会有脏数据的产生

双写的情况下是先更新数据库还是先操作缓存？我们来看下面这个情况

线程A发起一个写操作，第一步del cache
此时线程B发起一个读操作，cache miss
线程B继续读DB，读出来一个老数据
然后线程B把老数据设置入cache
线程A写入DB最新的数据
缓存和数据库的数据不一致了。缓存保存的是老数据，数据库保存的是新数据。因此，Cache-Aside缓存模式，选择了先操作数据库而不是先操作缓存。

​

还有一种策略是延迟双删写请求-删除缓存–>操作DB，休眠一会–>删除缓存

这种策略只是尽量减少数据不一致问题，像上面一样，这个休眠一会是很难做到精确为100%的，可能这个休眠一会还是早于更早因为网络延迟问题还没写入更早数据的操作

而且还是存在删除失败的情况，及时增加删除失败重试

还有一种策略是异步读取binlog，同步MQ，消息更新确认删除，但你这种就会有很大的异步带来的数据不一致情况

每种场景，要根据业务的不同要求合适使用

2、Read-Through/Write-Through（读写穿透）

Read/Write Through模式中，服务端把缓存作为主要数据存储。应用程序跟数据库缓存交互，都是通过抽象缓存层完成的。

从缓存读取数据，读到直接返回
如果读取不到的话，从数据库加载，写入缓存后，再返回响应。

Read-Through

增加了cache provider层，读取的时候从这里读取，没有在读取数据库，返回

由 cache provider层更细缓存

Write-Through
Write-Through模式下，当发生写请求时，也是由缓存抽象层完成数据源和缓存数据的更新,流程如下：

3、Write behind （异步缓存写入）

Write behind跟Read-Through/Write-Through有相似的地方，都是由Cache Provider来负责缓存和数据库的读写。它两又有个很大的不同：Read/Write Through是同步更新缓存和数据的，Write Behind则是只更新缓存，不直接更新数据库，通过批量异步的方式来更新数据库。

这种方式下，缓存和数据库的一致性不强，对一致性要求高的系统要谨慎使用。但是它适合频繁写的场景，MySQL的InnoDB Buffer Pool机制就使用到这种模式。