mysql redis保证数据一致性

1. 数据一致性：就是保证mysql与redis数据一致，在系统中一致性可分为：强一致性，弱一致性，最终一致性（最终一致性是弱一致性的一个特例）

   （1）强一致性：要求系统写入什么 读出来就是什么

   （2）弱一致性：系统写入成功后，不会立即读到写入的值，但会尽可能保证到某个时间级别内数据能够达到一致

   （3）最终一致性：系统会保证在一定时间内达到数据一致。它是业界在大型分布式系统数据一致性上比较推崇的模型

2. 经典缓存同步模式
   （1）Cache-Aside Pattern，即旁路缓存模式，它的提出是为了尽可能地解决缓存与数据库的数据不一致问题。
   
   读的时候先读缓存，缓存命中的话，返回数据
   缓存没有命中，读mysql，从数据库取出数据更新缓存，并返回数据
   
   更新的时候先更新数据库，再删除缓存
   A.问题：这里为什么不是更新数据库后再更新缓存，而是更新数据库后删除缓存
   Q
   
   线程A先发起一个写操作，第一步先更新数据库
   线程B再发起一个写操作，第二步更新了数据库
   由于网络等原因，线程B先更新了缓存
   线程A更新缓存。

   这时候，缓存保存的是A的数据（老数据），数据库保存的是B的数据（新数据），数据不一致了，脏数据出现啦。如果是删除缓存取代更新缓存则不会出现这个脏数据问题。

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

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

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

Q.
线程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（分区容错性），三者不可得兼。

3. 延迟双删解决缓存删除失败问题，
   缓存延时双删流程
   
   先删除缓存

   再更新数据库

   休眠一会（比如1秒），再次删除缓存。

   这个休眠一会，一般多久呢？都是1秒？

   这个休眠时间 = 读业务逻辑数据的耗时 + 几百毫秒。为了确保读请求结束，写请求可以删除读请求可能带来的缓存脏数据。

4. 删除缓存重试机制
   
   写请求更新数据库

   缓存因为某些原因，删除失败

   把删除失败的key放到消息队列

   消费消息队列的消息，获取要删除的key

   重试删除缓存操作

5. 读取biglog异步删除缓存
   
   以mysql为例

   可以使用阿里的canal将binlog日志采集发送到MQ队列里面然后通过ACK机制确认处理这条更新消息，删除缓存，保证数据缓存一致性