缓存和数据库数据一致性

说起这个话题，一般讨论的都是数据库的update操作和缓存delete(key)的执行策略问题。

为什么不是更新缓存而是删除缓存？

因为很多场景缓存的内容都是聚合数据，比如是几张表的数据聚合到一起，或者是需要经过大量计算才能得出结果的数据。

所以没必要每次更新时都重新算一遍，直接删除，等更新后的get请求进来，会从新计算放入缓存中的。

还有一种可能就是并发update的时候，没办法保证缓存set的顺序和数据库update的顺序是一致的。

我的结论

先数据库 update，后缓存 del key

Facebook在一篇论文中提到过，他们用的就是这个方案，但是并不是没问题的，是存在数据不一致情况的，不过概率很低。

案例1

1. req1查询数据A
2. 数据A缓存正好在这时过期失效
3. req1从数据库中得到旧数据数据A
4. req2更新数据A
5. req2删除了缓存
6. req1将查到旧数据写入了缓存

     为什么说概率低，因为触发的前置条件比较苛刻。

     1：正好赶上了缓存过期失效

     2：读请求比写请求执行的慢

1、先del 再update

案例2

1. req1查询数据A
2. req2先删除了缓存
3. req1从数据库中得到旧数据数据A
4. req2更新数据A
5. req1将查到旧数据写入了缓存

     这肯定是不行的，这样出错概率极大。

     上述2个案例对比，你会发现，案例2，只要并发读写，就完蛋。

2、先del 再update 最后del

     套用案例1，结果是一样的，而且多了一次del操作。

     人工del和案例1中的key过期是一样的效果，这就相当于每次更新数据，key都”恰巧“被”过期“。

     另外，先del，并发读写的时候，select全部打到数据库了，你这就是人为的制造“缓存击穿”。

3、update后，sleep一会，再 del key

      乍一看挺有道理的，好像解决了方案1的不足，可以把因为并发导致写入的旧缓存删除。

      我只能说，千万别被钓鱼，面试你可别这么说。

      这个思路是可行的，但是你别说sleep啊。

      专业一些：异步延时删除

      方案也很多，可以自己实现，可以通过订阅binlog，再配合删除失败的重试机制，比如mq

4、串行化的方案就忽略吧

结束语

仔细想想，异步延时删除，不就是 【先更新数据库，后删除缓存】的一种具体方案描述么。

核心依然是，后删除缓存，只不过区别在于怎么删除、何时删除 缓存而已。