讲讲 Redis 缓存更新一致性，看了都说好！

逃离我推掉我的手 2023-09-23 15:54 63阅读 0赞

当执行写操作后，需要保证从缓存读取到的数据与数据库中持久化的数据是一致的，因此需要对缓存进行更新。

![d9461d6c4fcdc61fec952992dee2e5f5.png][]

因为涉及到数据库和缓存两步操作，难以保证更新的原子性。

在设计更新策略时，我们需要考虑多个方面的问题:

*  对系统吞吐量的影响：比如更新缓存策略产生的数据库负载小于删除缓存策略的负载
 *  并发安全性：并发读写时某些异常操作顺序可能造成数据不一致，如缓存中长期保存过时数据
 *  更新失败的影响：若某个操作失败，如何对业务影响降到最小
 *  检测和修复故障的难度: 操作失败导致的错误会在日志留下详细的记录容易检测和修复。并发问题导致的数据错误没有明显的痕迹难以发现，且在流量高峰期更容易产生并发错误产生的业务风险较大。

更新缓存有两种方式:

*  删除失效缓存: 读取时会因为未命中缓存而从数据库中读取新的数据并更新到缓存中
 *  更新缓存: 直接将新的数据写入缓存覆盖过期数据

更新缓存和更新数据库有两种顺序：

*  先数据库后缓存
 *  先缓存后数据库

两两组合共有四种更新策略，现在我们逐一进行分析。

并发问题通常由于后开始的线程却先完成操作导致，我们把这种现象称为“抢跑”。下面我们逐一分析四种策略中“抢跑”带来的错误。

##  ##

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

若数据库更新成功，删除缓存操作失败，则此后读到的都是缓存中过期的数据，造成不一致问题。

可能存在读写线程竞争导致的并发错误:

![b2f8621ad96f8cde6e782677ef173336.png][]

##  ##

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

同删除缓存策略一样，若数据库更新成功缓存更新失败则会造成数据不一致问题。

该策略同样存在读写线程竞争导致数据不一致的问题:

![d82921445278ec982f3be98ecf0c65b9.png][]

也可能因为两个写线程竞争导致并发错误:

![fbb36b0501a9cac15864d47c190dbf2b.png][]

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

可能发生的并发错误:

![4353145237726407ae0dde615effa891.png][]

##  ##

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

若缓存更新成功数据库更新失败， 则此后读到的都是未持久化的数据。因为缓存中的数据是易失的，这种状态非常危险。

因为数据库因为键约束导致写入失败的可能性较高，所以这种策略风险较大。

可能发生的并发错误:

![5e5775567043b20428a80be331a4f87c.png][]

两个写线程竞争也会导致数据不一致:

解决方案

## 使用 CAS ##

CAS (Check-And-Set 或 Compare-And-Swap)是一种常见的保证并发安全的手段。CAS 当且仅当客户端最后一次取值后该 key 没有被其他客户端修改的情况下，才允许当前客户端将新值写入。

func CAS(oldVal, newVal) {
           if cache.get() == oldVal {
               cache.set(newVal)    }}

我们以上文提到的「先更新数据库，再更新缓存」方案中两个写线程竞争为例，尝试使用 CAS 来解决这个并发问题：

由上图可见，CAS 可以有效的避免并发错误的发生。

目前一些兼容 Redis 协议的中间件已经提供了 CAS 命令的支持，比如阿里的 Tair 以及腾讯的 Tendis。

Redis 官方提供了 Watch + 事务的方法来支持 CAS, 或者使用 redis 中 lua 脚本原子性执行的特点来实现 CAS。不过由于代码较为复杂，这两种方案都不常见。

## 使用分布式锁 ##

CAS 假设发生并发问题的概率不大, 所以 CAS 也被称为乐观锁。那么悲观锁能否解决我们的问题呢？

还是以「先更新数据库，再更新缓存」方案中两个写线程竞争为例， 我们要求任何线程在写入或读取数据库前都需要获取排它锁。

<table style="width:677px;"> 
 <thead> 
  <tr> 
   <th>时间</th> 
   <th>线程A</th> 
   <th>线程B</th> 
   <th>数据库</th> 
   <th>缓存</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>0</td> 
   <td></td> 
   <td></td> 
   <td>v0</td> 
   <td>v0</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>获取排它锁</td> 
   <td></td> 
   <td>v0</td> 
   <td>v0</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>更新数据库为 v1</td> 
   <td></td> 
   <td>v1</td> 
   <td>v0</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>更新缓存为 v1</td> 
   <td></td> 
   <td>v1</td> 
   <td>v1</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td></td> 
   <td>等待排它锁</td> 
   <td>v1</td> 
   <td>v1</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>释放排它锁</td> 
   <td></td> 
   <td>v1</td> 
   <td>v1</td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td></td> 
   <td>获得排它锁</td> 
   <td>v1</td> 
   <td>v1</td> 
  </tr> 
  <tr> 
   <td>7</td> 
   <td></td> 
   <td>更新数据库为 v2</td> 
   <td>v2</td> 
   <td>v1</td> 
  </tr> 
  <tr> 
   <td>8</td> 
   <td></td> 
   <td>更新缓存为 v2</td> 
   <td>v2</td> 
   <td>v2</td> 
  </tr> 
  <tr> 
   <td>9</td> 
   <td></td> 
   <td>释放排它锁</td> 
   <td>v2</td> 
   <td>v2</td> 
  </tr> 
 </tbody> 
</table>

分布式锁同样可以解决并发问题，只是成本可能略高。

异步更新

阿里开源了 MySQL 数据库binlog的增量订阅和消费组件 - canal。canal 模拟从库获得主库的 binlog 更新，然后将更新数据写入 MQ 或直接进行消费。

我们可以让API服务器只负责写入数据库，另一个线程订阅数据库 binlog 增量进行缓存更新。

因为 binlog 是有序的，因此可以避免两个写线程竞争。但我们仍然需要解决读写线程竞争的问题:

这里同样可以 CAS 解千愁：

延时双删

使用删除缓存策略时读线程先开始却后写缓存会导致不一致，那么我们在读线程结束后再次清除缓存是不是就可以解除错误状态了？延时双删就是写线程等待一段时间“确保”读线程都结束后再次删除缓存，以此清除可能的错误缓存数据。

理论上我们无法给出一个时间来“确保”读线程都结束，所以仍有存在并发问题的可能。但是延时双删实现成本很低而且极大的减少了并发问题出现的概率，不失为一种简单实用的手段。

[d9461d6c4fcdc61fec952992dee2e5f5.png]: https://img-blog.csdnimg.cn/img_convert/d9461d6c4fcdc61fec952992dee2e5f5.png
[b2f8621ad96f8cde6e782677ef173336.png]: https://img-blog.csdnimg.cn/img_convert/b2f8621ad96f8cde6e782677ef173336.png
[d82921445278ec982f3be98ecf0c65b9.png]: https://img-blog.csdnimg.cn/img_convert/d82921445278ec982f3be98ecf0c65b9.png
[fbb36b0501a9cac15864d47c190dbf2b.png]: https://img-blog.csdnimg.cn/img_convert/fbb36b0501a9cac15864d47c190dbf2b.png
[4353145237726407ae0dde615effa891.png]: https://img-blog.csdnimg.cn/img_convert/4353145237726407ae0dde615effa891.png
[5e5775567043b20428a80be331a4f87c.png]: https://img-blog.csdnimg.cn/img_convert/5e5775567043b20428a80be331a4f87c.png