在高并发场景下，先更新缓存还是先更新数据库

共计 2481 个字符，预计需要花费 7 分钟才能阅读完成。

本篇内容主要讲解“在高并发场景下，先更新缓存还是先更新数据库”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“在高并发场景下，先更新缓存还是先更新数据库”吧!

在大型系统中，为了减少数据库压力通常会引入缓存机制，一旦引入缓存又很容易造成缓存和数据库数据不一致，导致用户看到的是旧数据。

为了减少数据不一致的情况，更新缓存和数据库的机制显得尤为重要，接下来带领大家踩踩坑。

Cache aside

Cache aside 也就是旁路缓存，是比较常用的缓存策略。

(1)读请求常见流程

Cache aside 读请求

应用首先会判断缓存是否有该数据，缓存命中直接返回数据，缓存未命中即缓存穿透到数据库，从数据库查询数据然后回写到缓存中，最后返回数据给客户端。

(2)写请求常见流程

Cache aside 写请求

首先更新数据库，然后从缓存中删除该数据。

看了写请求的图之后，有些同学可能要问了：为什么要删除缓存，直接更新不就行了? 这里涉及到几个坑，我们一步一步踩下去。

Cache aside 踩坑

Cache aside 策略如果用错就会遇到深坑，下面我们来逐个踩。

踩坑一：先更新数据库，再更新缓存

如果同时有两个写请求需要更新数据，每个写请求都先更新数据库再更新缓存，在并发场景可能会出现数据不一致的情况。

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

如上图的执行过程：

(1)写请求 1 更新数据库，将 age 字段更新为 18;

(2)写请求 2 更新数据库，将 age 字段更新为 20;

(3)写请求 2 更新缓存，缓存 age 设置为 20;

(4)写请求 1 更新缓存，缓存 age 设置为 18;

执行完预期结果是数据库 age 为 20，缓存 age 为 20，结果缓存 age 为 18，这就造成了缓存数据不是最新的，出现了脏数据。

踩坑二：先删缓存，再更新数据库

如果写请求的处理流程是先删缓存再更新数据库，在一个读请求和一个写请求并发场景下可能会出现数据不一致情况。

先删缓存，再更新数据库

如上图的执行过程：

(1)写请求删除缓存数据;

(2)读请求查询缓存未击中(Hit Miss)，紧接着查询数据库，将返回的数据回写到缓存中;

(3)写请求更新数据库。

整个流程下来发现数据库中 age 为 20，缓存中 age 为 18，缓存和数据库数据不一致，缓存出现了脏数据。

踩坑三：先更新数据库，再删除缓存

在实际的系统中针对写请求还是推荐先更新数据库再删除缓存，但是在理论上还是存在问题，以下面这个例子说明。

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

如上图的执行过程：

(1)读请求先查询缓存，缓存未击中，查询数据库返回数据;

(2)写请求更新数据库，删除缓存;

(3)读请求回写缓存;

整个流程操作下来发现数据库 age 为 20，缓存 age 为 18，即数据库与缓存不一致，导致应用程序从缓存中读到的数据都为旧数据。

但我们仔细想一下，上述问题发生的概率其实非常低，因为通常数据库更新操作比内存操作耗时多出几个数量级，上图中最后一步回写缓存 (set age  18) 速度非常快，通常会在更新数据库之前完成。

如果这种极端场景出现了怎么办? 我们得想一个兜底的办法：缓存数据设置过期时间。通常在系统中是可以允许少量的数据短时间不一致的场景出现。

Read through

在 Cache Aside 更新模式中，应用代码需要维护两个数据源头：一个是缓存，一个是数据库。而在 Read-Through   策略下，应用程序无需管理缓存和数据库，只需要将数据库的同步委托给缓存提供程序 Cache Provider 即可。所有数据交互都是通过抽象缓存层完成的。

Read-Through 流程

如上图，应用程序只需要与 Cache Provider 交互，不用关心是从缓存取还是数据库。

在进行大量读取时，Read-Through   可以减少数据源上的负载，也对缓存服务的故障具备一定的弹性。如果缓存服务挂了，则缓存提供程序仍然可以通过直接转到数据源来进行操作。

Read-Through 适用于多次请求相同数据的场景，这与 Cache-Aside 策略非常相似，但是二者还是存在一些差别，这里再次强调一下：

在 Cache-Aside 中，应用程序负责从数据源中获取数据并更新到缓存。

在 Read-Through 中，此逻辑通常是由独立的缓存提供程序 (Cache Provider) 支持。

Write through

Write-Through 策略下，当发生数据更新 (Write) 时，缓存提供程序 Cache Provider 负责更新底层数据源和缓存。

缓存与数据源保持一致，并且写入时始终通过抽象缓存层到达数据源。

Cache Provider 类似一个代理的作用。

Write-Through 流程

Write behind

Write behind 在一些地方也被成为 Write back，简单理解就是：应用程序更新数据时只更新缓存，Cache  Provider 每隔一段时间将数据刷新到数据库中。说白了就是延迟写入。

Write behind 流程

如上图，应用程序更新两个数据，Cache Provider 会立即写入缓存中，但是隔一段时间才会批量写入数据库中。

这种方式有优点也有缺点：

优点是数据写入速度非常快，适用于频繁写的场景。

缺点是缓存和数据库不是强一致性，对一致性要求高的系统慎用。

总结

学了这么多，相信大家对缓存更新的策略都已经有了清晰的认识。最后稍稍总结一下。

缓存更新的策略主要分为三种：

Cache aside

Read/Write through

Write behind

Cache aside 通常会先更新数据库，然后再删除缓存，为了兜底通常还会将数据设置缓存时间。

Read/Write through 一般是由一个 Cache Provider 对外提供读写操作，应用程序不用感知操作的是缓存还是数据库。

Write behind 简单理解就是延迟写入，Cache Provider 每隔一段时间会批量输入数据库，优点是应用程序写入速度非常快。

到此，相信大家对“在高并发场景下，先更新缓存还是先更新数据库”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！