Redis与MySQL双写一致性

最新推荐文章于 2022-03-16 15:20:11 发布

不带刺仙人球

最新推荐文章于 2022-03-16 15:20:11 发布

阅读量96

点赞数

分类专栏：数据库文章标签：一致性

本文链接：https://blog.csdn.net/zyzn1425077119/article/details/117669575

版权

数据库专栏收录该内容

10 篇文章 0 订阅

订阅专栏

参考：https://mp.weixin.qq.com/s/VtB3cdTGB67iqok5pxYyhw

一致性：强一致性、弱一致性、最终一致性。

弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态
最终一致性：最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型

三个经典的缓存模式

Cache-Aside Pattern
Read-Through/Write-through
Write-behind

一、Cache-Aside Pattern

Cache-Aside Pattern，即旁路缓存模式，它的提出是为了尽可能地解决缓存与数据库的数据不一致问题。

Cache-Aside读流程

Cache-Aside Pattern的读请求流程如下：

读的时候，先读缓存，缓存命中的话，直接返回数据
缓存没有命中的话，就去读数据库，从数据库取出数据，放入缓存后，同时返回响应。

Cache-Aside 写流程

Cache-Aside Pattern的写请求流程如下：

更新的时候，先更新数据库，然后再删除缓存。

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

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

Read-Through

Read-Through的简要流程如下

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

多了一层Cache-Provider而已，应用程序请求，Cache Provider 去缓存获取数据，如无的话，向数据库获取，之后put(key,entity)缓存，之后从缓存获取值，返回。

Write-Through

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

应用程序->Cache Provider --更新->数据源----->更新缓存

三、Write-behind （异步缓存写入）

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

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