缓存与数据库一致性之延迟双删策略

场景

一般一些热点数据我们都会通过同步到缓存，让请求命中到缓存而非穿透到数据库的形式来降低数据库的压力。这确实是目前互联网用得最多的保护数据库的方案，但是这样也会衍生出一些问题，最常见的就是缓存内数据和数据库数据并非同步的。

例

A例：先删除缓存数据，然后更新数据库：假设A请求删除了缓存数据，B请求来获取数据，查询不到数据时，认为是数据过期了，直接拿数据库内的数据并且填充到缓存了。这时A请求才去更新数据库，而缓存数据已经被B拿旧数据填充了。这样缓存和数据库就不是一致的了。

B例：先更新数据库，再删除缓存数据：假设A请求更新了数据库，还未情况缓存的情况下，B请求拿到的是缓存内的旧数据，因为A还没来得及把新的数据填充到缓存。

双删策略

这里指的是删除两次缓存，首先删除缓存，然后更新数据库，为了避免有其他的请求拿错误的数据覆盖到了缓存，再次删除掉缓存，让下一次的请求命中到数据库，从而把最新的数据填充到缓存。

这就是比A例子多一个再次删除缓存的操作，这样就能避免一些问题。

延迟双删策略

为什么会存在延迟双删呢，普通的双删时，假设B请求获取到了旧数据，准备填充到缓存，A请求刚刚更新完数据库，立刻删除了缓存，在删除完成后B请求才把旧数据去填充，这样依然会出现缓存与数据库不一致的情况（即缓存内数据错误）。

延迟双删就是A请求更新完数据库之后，延迟那么一会再去删除缓存，这样的目的也很明显，就是为了让B请求（以及其他很多相近时间的请求）已经拿旧数据填充过缓存了，并且已经走完这一段逻辑了，后续不会去尝试覆盖缓存了。这个时候再去删除缓存，下一次去填充缓存的时候就拿到的是A请求更新好的正确的数据了。

后记

其实看完延迟双删之后，大家也估计都注意到了一个问题，就是会存在一段时间的错误数据，以及穿透到数据库的情况。延迟双删只是能避免一部分数据不一致问题，但是不是一种最完美的解决方案，对于一些数据实时性要求高的场景，或者并发大的场景其实不是完全适用的。不过技术这条路，大家都是选择适合自己场景的，这个利弊以及适配度需要开发者自己把握咯。