mysql cache一致性问题

https://blog.csdn.net/ly262173911/article/details/75127339

http://www.cnblogs.com/duyinqiang/p/5696253.html

1 选蓝色字体方案，不要选红色方案。具体解释见下方文字：

为了减少db的读压力，加快读速度，系统使用cache做缓存，会引起cache一致性问题。因为db会有事务性导致回滚，而cache无法回滚，会导致脏数据。

一般情况下，我们会在保存数据时，先穿透保存到DB中，再同步数据到redis中。

为了保证存储层对外层透明，我们会把DB与redis操作封装，对上层调用来说完全透明，不关心数据具体如何存储。

例如在我们的实际业务中有如下场景：A表插入一条数据，同步到redis中，B表插入一条数据，同步到redis中。如果B表插入数据失败，事务回滚，A表中数据可以回滚，但是redis无法回滚。会导致redis中有脏数据。

facebook的一篇论文给出如下设计：

查询：先查询cache，miss时查询db，写入cache

写：写db成功后，失效cache

重点说下写：如果写db成功后，写cache，会有事务性和并发性两方面问题。

1.事务性问题：一个事务包含多个db操作，操作一些db成功，写cache成功，操作二写db失败，事务回滚，db数据回滚，cache无法回滚，导致脏数据。

2.并发性问题：两个更新操作并发，如更新名字，并且cache中key以名字为关键字，更新一写db成功，写缓存XXXX_name1成功。更新二写db成功，写缓存XXXX_name2成功。导致cache脏数据。

二 ：选蓝色方案可能出现以下问题

一、需求缘起

上一篇《缓存架构设计细节二三事》（点击查看）引起了广泛的讨论，其中有一个结论：当数据发生变化时，“先淘汰缓存，再修改数据库”这个点是大家讨论的最多的。

 

上篇文章得出这个结论的依据是，由于操作缓存与操作数据库不是原子的，非常有可能出现执行失败。

假设先写数据库，再淘汰缓存：第一步写数据库操作成功，第二步淘汰缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致【如上图：db中是新数据，cache中是旧数据】。

 

假设先淘汰缓存，再写数据库：第一步淘汰缓存成功，第二步写数据库失败，则只会引发一次Cache miss【如上图：cache中无数据，db中是旧数据】。

 

结论：先淘汰缓存，再写数据库。

 

引发大家热烈讨论的点是“先操作缓存，在写数据库成功之前，如果有读请求发生，可能导致旧数据入缓存，引发数据不一致”，这就是本文要讨论的主题。

 

二、为什么数据会不一致

回顾一下上一篇文章中对缓存、数据库进行读写操作的流程。

写流程：

（1）先淘汰cache

（2）再写db

读流程：

（1）先读cache，如果数据命中hit则返回

（2）如果数据未命中miss则读db

（3）将db中读取出来的数据入缓存

 

什么情况下可能出现缓存和数据库中数据不一致呢？

在分布式环境下，数据的读写都是并发的，上游有多个应用，通过一个服务的多个部署（为了保证可用性，一定是部署多份的），对同一个数据进行读写，在数据库层面并发的读写并不能保证完成顺序，也就是说后发出的读请求很可能先完成（读出脏数据）：

（a）发生了写请求A，A的第一步淘汰了cache（如上图中的1）

（b）A的第二步写数据库，发出修改请求（如上图中的2）

（c）发生了读请求B，B的第一步读取cache，发现cache中是空的（如上图中的步骤3）

（d）B的第二步读取数据库，发出读取请求，此时A的第二步写数据还没完成，读出了一个脏数据放入cache（如上图中的步骤4）

即在数据库层面，后发出的请求4比先发出的请求2先完成了，读出了脏数据，脏数据又入了缓存，缓存与数据库中的数据不一致出现了