为了减少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脏数据。

这里再说一下一般更新操作顺序是失效cache，写db，写cache。会有并发问题。

两个并发操作，更新和读，左边写线程，右边为读线程

①更新操作删除cache

②读操作读cache，miss

③读db，此时是旧数据

④写db，写cache

⑤写cache 导致cache中脏数据。

虽然写db成功后，失效cache也会有并发问题：更新和读并发

①查询cache

②写db，失效cache

③写chache

导致cache中脏数据，但是概率极低，并且一般db中写时间长于读时间，并且写会锁表，读需要在写前进入，并且要晚于写操作更新缓存，所以发生概率极低。

解决方法是 2PC或是Paxos协议，代价较大。

所以我们采用的方式是：

写数据只写db

更新数据先更新db，再失效cache

读数据，先读cache，未命中读db，写入cache