怎么保证缓存与数据库的最终一致性？

目录

零.读数据的标准操作

一.Cache aside Patten--旁路模式

二.Read/Write Through Pattern--读写穿透

三.Write Back Pattern--写回

四.运用canal监听mysql的binlog实现缓存同步

---

零.读数据的标准操作

这里想说的是不管哪种模式读操作都是一样的，这是一种统一的规范：

但写操作却五花八门。

一.Cache aside Patten--旁路模式

这个是最常见的模式。运用于读多写少的情况。

1.为什么采用更新而不是删除
更新缓存：每次更新数据库都更新缓存，无效写操作较多
删除缓存：更新数据库时让缓存失效，查询时再更新缓存
2.我们应当是先操作数据库，再删除缓存，而不应该反过来

原因在于，如果你选择第一种方案，在两个线程并发来访问时，假设线程1先来，他先把缓存删了，此时线程2过来，他查询缓存数据并不存在，此时他写入缓存，当他写入缓存后，线程1再执行更新动作时，实际上写入的就是旧的数据，新的数据被旧数据覆盖了。 

二.Read/Write Through Pattern--读写穿透

简单说就是神挡杀神，佛挡杀佛。前面有什么就更新什么。

Write-Through的潜在使用场景是银行系统。

Write-Through适用情况有：

        需要频繁读取相同数据

        不能忍受数据丢失（相对Write-Behind而言）和数据不一致

在使用Write-Through时要特别注意的是缓存的有效性管理，否则会导致大量的缓存占用内存资源。甚至有效的缓存数据被无效的缓存数据给清除掉。

三.Write Back Pattern--写回

在更新数据的时候，先更新缓存，再异步批量更新数据库。

适合读多写多的操作，如果采用Cache Aside Pattern，由于更新的频繁，也频繁删除缓存。读操作如果很少命中缓存，缓存也失去了意义。

Write Behind Pattern优点是效率很高，数据库压力很小，将数据库的读和写操作多落在缓存上。(可以使用消息队列或者定时任务实现)

缺点：异步增大了数据库和缓存无法强一致的概率。

比如说当过期的时候去读取，可能使得同一时间点赞或者取消点赞的数据更改并没有同步到缓存。一般结合前端缓存进行优化用户体验。适用于对数据一致性要求不那么高的场景，比如高并发下的点赞和收藏，还有浏览量等场景

新问题：Write-Behind 这种以cache为主的模式，是可能会丢数据的

DB挂了，少写数据，但是只要数据还在redis能追回来
redis挂了，服务感知到后降级，请求回源，​“缓存击穿”​

四.运用canal监听mysql的binlog实现缓存同步

大厂模式主要是通过监听数据库的binlog(比如mysql binlog)；通过binlog把数据库数据的更新操作日志（比如insert,update,delete），采集到后，通过MQ的方式，把数据同步给下游对应的消费者；下游消费者拿到数据的操作日志并拿到对应的业务数据后，再放入缓存。

大概流程图：

优点：
1、把操作缓存的代码逻辑，从正常的业务逻辑里解耦出来；业务代码更加清爽和简洁，两者互不干扰和影响，独立发展。用非人类的话说，减少对业务代码的侵入性。
2、曾经有幸在大厂里实践过此种方案，速度还贼快，虽然从库到缓存经过了类canal和mq中间件，但基本上耗时都是在毫秒级，99.9%都是10毫秒内能完成库里的数据和缓存数据同步（大厂的优势出来了）

缺点：
1、技术方案和架构，非常复杂
2、中间件的运维和维护，是个不小的工作量
3、由于引入了MQ需要解决引入MQ后带来的问题。比如数据乱序问题：同一条数据先发后至，后发先至的到达消费者后，从而引起的MQ乱序消费问题。但一般都能解决（比如通过redis lua+数据的时间戳比较方案，解决并发问题和数据乱序问题）

在大厂里，不缺类似canal这种伪装为数据库slave节点的自研中间件，并且大厂里也有足够的技术高手+物料，运维资源更是不缺；对小厂来说，慎用吧。

五.定时更新+增量查询

定时更新+增量查询：主要是利用库里行数据的更新时间字段+定时增量查询。
具体为：每次更新库里的行数据，记录当前行的更新时间；然后把更新时间做为一个索引字段（加快查询速度嘛）

定时任务：会每隔5秒钟（间隔时间可自定义）；把库里最近更新5秒钟的数据查询出来；然后放入缓存，并记录本次查询结束时间。
整个查询过程和放入缓存的过程都是单线程执行；所以不会存在并发更新缓存问题。另外每次同步成功后，会记录同步成功时间；下次定时任务再执行时，会拿上次同步成功时间，做为本次查询开始时间条件；当前时间做为查询结束时间，以此达到增量查询的目标。
再加上查询条件里更新时间是个索引，性能也差不到哪里去。
即使偶尔的定时任务执行失败或者没有执行，也不会丢失数据，只要定时任务恢复了。

优点：
1、实现方案，和架构很简单。是的，比起大厂那套方案，简直不要太轻量。
2、也能把缓存逻辑和业务逻辑进行解耦
3、三方依赖也比较少。如果有条件可以上个分布式定时中间件比如 xxl-job，实在不行就用redis做个分布式锁也能用
缺点：
1、数据库里的数据和缓存中数据，会在极短时间内，存在不一致，但最终会是一致的。这个极短的时间，取决于定时调度间隔时间，一般在秒级。
2、如果是分库分表的业务，编写这个查询逻辑，估计会稍显复杂。

如果业务上不是要求毫秒级的及时性，也不是类似于价格这种非常敏感的数据，这种轻量级方案还真不错。无并发问题，也无数据乱序问题；秒级数据量超过几十万的增量数据并且还需要缓存的，怕是只有大厂才有的场景吧；怎么看此方案都非常适合中小公司。

六.延时双删

前面的旁路模式有个数据一致性的问题，就是说我们的键不存在了，然后去数据库查询放到缓存，刚刚查询完，然后突然数据库的数据更新并又删除了一下键，这时候执行将查询的数据放到缓存的操作，而此时放到缓存的数据是旧的数据。

此时我们可以使用延迟双删策略提高数据一致性的概率。【但不能完全解决数据一致性的问题。更加严格的数据一致性保证需要使用更复杂的机制，比如使用消息队列等】

伪代码：

#删除缓存
redis.delKey(X)
#更新数据库
db.update(X)
#睡眠
Thread.sleep(N)
#再删除缓存
redis.delKey(X)

通过延时双删策略，可以保证在数据库更新期间，其他读取请求在缓存不命中的情况下，会直接读取数据库的最新数据，而不会读取到已经失效的缓存数据。这样就保证了数据的一致性和缓存的即时更新。

延时双删策略虽然会增加一次缓存删除的开销，但是可以有效地提高数据的一致性，并且在高并发读取的场景下，减轻数据库的读取压力，提高读取性能和响应速度。