欧阳亮的博客

编程不止是一份工作,还是一种乐趣!!!

Redis缓存数据一致性

在互联网行业,使用缓存来提升应用的性能已经是一件非常常见的手段,但是如何保证缓存与数据库的一致性确不是一件容易的事。比如下面的场景都可会导致数据不一致性。

  • 场景1:更新数据库成功,更新缓存失败,数据不一致;
  • 场景2:更新缓存成功,更新数据库失败,数据不一致;
  • 场景3:更新数据库成功,清除缓存失败,数据不一致;
  • 场景4:清除缓存成功,更新数据库失败,数据弱一致;


缓存和数据库是两类不同的存储资源,如果要追求绝对的数据一致性,唯一的办法就是分布式事务。但使用分布式事务又会引入严重的写入性能损耗,在大多数情况下,业务上是无法接受这样的损耗的。所以更多的时候,我们追求的是数据的最终一致性,一种比较折中的实现是这样的:

写操作读操作
1. 清除缓存;若失败则返回错误信息(本次写操作失败)。
2. 更新数据库;若失败则返回错误信息(本次写操作失败),此时数据弱一致。
3. 更新缓存,即使失败也返回成功,此时数据弱一致。
1. 查询缓存,命中则直接返回结果。
2. 查询数据库,将结果直接写入缓存,返回结果。


这种实现简单明了,尤其是读操作,一看即明白。对于写操作,会有朋友问为什么第一步要先清除缓存。大家可以想想,如果去掉第一步,那么写操作就可能发生最开始我们提到的场景1的情况:更新数据库成功,更新缓存失败,数据不一致。如果在写操作的第一步先清除缓存,对于场景1的情况,那结果会是数据库中有值,而缓存中无值,即数据弱一致,并不会造成业务错误。


如果你认为上面的实现已经完美,那你可能会失望了。在并发场景中,它并不安全。我们看一个简单的例子:假如有一个用户,它的账户中有100块钱。现在有两个并发的请求:请求1为写操作,更新用户的余额,从100更新为200;请求2为查询操作,查询用户的余额。由于是并发的,两个请求之间的执行顺序是不确定的,我们来看一下下面的执行顺序:

  1. 请求1首先清除用户的缓存。
  2. 接着请求2查询缓存,由于缓存中没有数据,请求2继续查询数据库,得到余额为100。
  3. 请求1更新数据库,并将结果写入缓存。此时,数据库与缓存中的余额都是200。
  4. 请求2将数据库查询结果100写入缓存。
  5. 最终,余额在数据库中是200,而在缓存中是100,数据不一致。


造成这样的结果,原因有两个方面:一是写操作中更新数据库与更新缓存是两个操作,而不是一个原子操作;二是读操作中读取数据库和写入缓存两个操作不是原子的。要解决这个问题,需要做一些修改,引入分布式锁:

写操作读操作
1.清除缓存;若失败则返回错误信息(本次写操作失败)。
2.对key加分布式锁。
3.更新数据库;若失败则返回错误信息(本次写操作失败)同时释放锁,此时数据弱一致。
4.更新缓存,即使失败也返回成功,同时释放锁,此时数据弱一致。
1.查询缓存,命中则直接返回结果。
2.对key加分布式锁。
3.查询数据库,将结果直接写入缓存,返回结果,同时释放锁。


引入分布式锁后的实现,之前的并发引起的问题不复存在,读者可以自行验证。不过我们仔细分析一下读操作的实现,其实它还可以进一步的优化。如果第二步加锁的时候失败了,意味着同一时刻,有别的请求在进行同一个key的写操作或读操作,不论怎样,在别的请求完成之后,缓存中应该已经有(当然也可能没有,写操作和读操作最后更新缓存失败的情况下)我们需要的数据了,这时我们只需要等待一会再重新查询缓存即可,所以更优的读操作的实现:

  1. 查询缓存,命中则直接返回结果。
  2. 对key加分布式锁。如果加锁失败,则等待一会再重新跳回第1步开始重新执行。
  3. 查询数据库,将结果直接写入缓存,返回结果,同时释放锁。