认识达内从这里开始

缓存与数据库一致性问题是每一位软件编程开发程序员都需要长期关注的一个问题，下面我们就通过案例分析来简单了解一下，数据库缓存一致性问题应用方法。

1)更新数据库后同步删除缓存

这个同步删除缓存其实是为了解决我们上面说的那个异步binlog删除不一致时间窗口比较大的问题。更新完数据之后，我们马上进行一次同步删除，不一致的时间窗口非常小。

2)监听数据库的binlog异步删除缓存

该步骤是整个方案的核心，也就是方案3，因为binlog理论上是绝对不会丢的，他不像同步删除存在无法收敛入口的问题。因此，我们会保障该步骤一定能删除成功，如果出现失败，则通过MQ不断重试。

通过前面两个方案点，我们其实已经保障了绝大多数场景下数据是正确的。

3)缓存数据带过期时间，过期后自动删除，越近更新的数据过期时间越短

该策略的设计初衷是因为我们前面讲的那些并发问题其实都是在存在并发更新跟一些并发查询的场景下出现的，因此近刚刚更新过的数据，他出现不一致的概率相对于那种很久没更新过的数据来说会大很多。

例如近一个小时内更新的数据，我可能给他设计的过期时间很短，当然这个过期时间很多是相对于其他数据而言，绝对时间还是比较长的，例如我们使用的是一个小时。

这边是因为我们整体的请求量和数据量太大，如果使用的过期时间太短，会导致写缓存流量特别大，导致缓存集群压力很大。

因此，如果使用该策略，建议过期时间一开始可以设置大一点，然后逐渐往下调，同时观察缓存集群的压力情况。

该方案可以进一步保证我们数据的一个终一致性。

同时带过期时间可以解决另一个问题，如果你在缓存上线后发现缓存数据结构设计不合理，你想把该缓存替换掉。如果该缓存有过期时间，你不需要处理存量数据，让他到期自动删除就行了。如果该缓存没有过期时间，则你需要将存量数据进行删除，不然可能会占用大量空间。

4)监听数据库的binlog延迟N秒后进行数据一致性校验

这个操作也是非常关键，方案3存在的问题就可以通过这个操作来解决掉。就如上面提过的，脏数据都是在更新操作之后的很短时间内触发的。

因此，我们对每一个更新操作，都在延迟一段时间后去校验其缓存数据是否正确，如果不正确，则进行修复，这样就保障了绝大多数并发导致的脏数据问题。

至于延迟多久，我个人建议是延迟几分钟，不能延迟太短，否则起不到兜底的效果。

5)存在数据库更新的链路禁用对应缓存

在数据库更新的场景里面，我们可能会有一些查询操作。例如我更新完这个数据之后，我马上又查了一下。这个时候其实如果你去走缓存，很有可能是会存在脏数据。因为他更新完之后，马上读取这个间隔是非常短的。你的缓存其实可能还没有删除完，或者存在短期内的不一致，我们还没有修复。

但是这种更新场景他对数据的一致性要求一般是比较高的。因为更新完之后，他要拿这个查询出来的数据去做一些其他操作。例如记录数据变更的操作日志。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。