为了减少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
