db一致性 redis redis 一致性协议

转载

mob64ca13f7ecc9 2023-08-18 10:30:45

文章标签 db一致性 redis redis java 数据库缓存 文章分类 Redis 数据库

数据一致性：就是保证mysql与redis数据一致，在系统中一致性可分为：强一致性，弱一致性，最终一致性（最终一致性是弱一致性的一个特例）
（1）强一致性：要求系统写入什么读出来就是什么
（2）弱一致性：系统写入成功后，不会立即读到写入的值，但会尽可能保证到某个时间级别内数据能够达到一致
（3）最终一致性：系统会保证在一定时间内达到数据一致。它是业界在大型分布式系统数据一致性上比较推崇的模型
经典缓存同步模式
（1）Cache-Aside Pattern，即旁路缓存模式，它的提出是为了尽可能地解决缓存与数据库的数据不一致问题。

db一致性 redis redis 一致性协议_db一致性 redis

读的时候先读缓存，缓存命中的话，返回数据
缓存没有命中，读mysql，从数据库取出数据更新缓存，并返回数据

db一致性 redis redis 一致性协议_redis_02

更新的时候先更新数据库，再删除缓存
A.问题：这里为什么不是更新数据库后再更新缓存，而是更新数据库后删除缓存
Q

db一致性 redis redis 一致性协议_数据库_03

线程A先发起一个写操作，第一步先更新数据库
线程B再发起一个写操作，第二步更新了数据库
由于网络等原因，线程B先更新了缓存
线程A更新缓存。
这时候，缓存保存的是A的数据（老数据），数据库保存的是B的数据（新数据），数据不一致了，脏数据出现啦。如果是删除缓存取代更新缓存则不会出现这个脏数据问题。

更新缓存相对于删除缓存，还有两点劣势
如果你写入的缓存值，是经过复杂计算才得到的话。更新缓存频率高的话，就浪费性能啦。

在写数据库场景多，读数据场景少的情况下，数据很多时候还没被读取到，又被更新了，这也浪费了性能呢(实际上，写多的场景，用缓存也不是很划算的,哈哈)

A.问题双写的情况下是先操作数据库还是先操作缓存

db一致性 redis redis 一致性协议_缓存_04

线程A发起一个写操作，第一步del cache

此时线程B发起一个读操作，cache miss

线程B继续读DB，读出来一个老数据

然后线程B把老数据设置入cache

线程A写入DB最新的数据

缓存和数据库的数据不一致了。缓存保存的是老数据，数据库保存的是新数据。因此，Cache-Aside缓存模式，选择了先操作数据库而不是先操作缓存。

A.数据库和缓存数据保持强一致，可以嘛？

Q.实际上，没办法做到数据库与缓存绝对的一致性。

A.加锁可以嘛？并发写期间加锁，任何读操作不写入缓存.缓存及数据库封装CAS乐观锁，更新缓存时通过lua脚本？

Q.分布式事务，3PC？TCC？
其实，这是由CAP理论决定的。缓存系统适用的场景就是非强一致性的场景，它属于CAP中的AP。个人觉得，追求绝对一致性的业务场景，不适合引入缓存。
CAP理论，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。