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

目录

零.读数据的标准操作

一.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优点是效率很高，数据库压力很小，将数据库的读和写操作多落在缓存上。

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

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