从实战出发，聊聊缓存数据库一致性

在云服务中，缓存是极其重要的一点。所谓缓存，其实是一个高速数据存储层。当缓存存在后，日后再次请求该数据就会直接访问缓存，提升数据访问的速度。但是缓存存储的数据通常是短暂性的，这就需要经常对缓存进行更新。而我们操作缓存和数据库，分为读操作和写操作。

读操作的详细流程为，请求数据，如缓存中存在数据则直接读取并返回，如不存在则从数据库中读取，成功之后将数据放到缓存中。

写操作则又分为以下 4 种：

• 先更新缓存，再更新数据库

• 先更新数据库，再更新缓存

• 先删除缓存，再更新数据库

• 先更新数据库，再删除缓存

一些一致性要求不高的数据，如点赞数等，可以先更新缓存，然后再定时同步到数据库。而在其它情况下，我们通常会等数据库操作成功，再操作缓存。

下面主要介绍更新数据库成功后，更新缓存和删除缓存这两个操作的区别和改进方案。

先更新数据库，再删除缓存

先更新数据库，再删除缓存，这种模式也叫 cache aside，是目前比较流行的处理缓存数据库一致性的方法。 它的优点是：

• 出现数据不一致的概率极低，实现简单

• 由于不更新缓存，而是删除缓存，在并发写写情况下，不会出现数据不一致的情况

出现数据不一致的情况出现在并发读写的场景下，详情可见下图：

这种情况发生的概率比较低，必须要在某⼀时间区间同时存在两个或多个写⼊和多个读取，所以大部分业务都容忍了这种小概率的不一致。

虽然发生的概率较低，但还是有一些方案可以让影响降到更低。

优化方案

第一种方案为：采用较短的过期时间来减少影响。这种方法有两个缺点：

• 删除后，读请求会 miss

• 如果缓存不一致，不一致的时间取决于过期时间设置