缓存更新和数据库更新先后顺序

1、先更新缓存再更新数据库

1）读请求先查询缓存，缓存击中，查询数据库返回数据；
2）写请求更新数据库，删除缓存；
3）读请求回写缓存

2、先删除缓存再更新数据库

1）写请求删除缓存后；
2）读请求没有命中缓存，取数据库读到旧数据，回写到缓存；
3）写请求更新数据库，
4）如果没有写操作，在缓存中的数据则一直是老的数据。

3、先更新数据库再更新缓存

1）写请求1更新数据库；
2）写请求2更新数据库，写请求2更新缓存；
3）写请求1更新缓存
4）数据库和缓存数据不一致

4、先更新数据库再删除缓存

1）读请求先查询缓存，缓存未击中，查询数据库返回数据；
2）写请求更新数据库，删除缓存；
3）读请求回写缓存

虽然缓存和数据库数据不一致，但是发生概率极低，因为数据库更新操作比内存操作耗时大很多，最后一步回写缓存速度超级快，通常会在更新数据前完成，所以可以不考虑。可以给缓存数据设置过期时间，这样只是再极低概率下短时间内数据不一致，不影响后续查询。

5、淘汰缓存还是更新缓存：大部分情况，修改value成本会高于“增加一次cache miss”，因此应该淘汰缓存

结论：
推荐采用先更新数据库，后删除缓存，

引用篇尾原文链接里的话，原文：缓存更新的套路

云计算中的很多虚拟化技术的原理，和传统的虚拟内存不是很像么？Unix下的那些I/O模型，也放大到了架构里的同步异步的模型，还有Unix发明的管道不就是数据流式计算架构吗？TCP的好些设计也用在不同系统间的通讯中，仔细看看这些微观层面，你会发现有很多设计都非常精妙……所以，请允许我在这里放句观点鲜明的话——如果你要做好架构，首先你得把计算机体系结构以及很多老古董的基础技术吃透了。

看看相应的guideline，best practice或design pattern，吃透了已有的这些东西，再决定是否要重新发明轮子

也可参考：CANAL
参考链接：
很全面的对原文做了标注：
原文：缓存更新的套路
分布式系统的事务处理