高并发下的缓存一致性问题

Posted 2021-02-05 jylsgup

数据读取的时候：

先查缓存，缓存查不到查数据库，然后把查到的结果放到缓存中。这些都基本上没有争议。

 

但是数据更新的时候：

到底是先更新数据库，还是再更新（or删除）缓存

or 先更新（or删除）缓存，再更新数据库。

一直存在很大的争议。几种实现方式都会出现数据一致性问题。

 

我就说说目前我们系统是怎么做的：

0、先确认缓存命中率。不要动不动就上缓存，有些缓存命中率根本毫无意义，比如涉及到和账户相关的资产、订单等信息，就算放入缓存中，只有用户自己会去查自己的信息，命中率极低。

     一般是把与账户无关，且查询量较大的放入缓存中。     

1、缓存设置过期时间，保证最终一致性。

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

可能会出现更新数据库后，删除缓存失败，导致缓存是旧数据，数据库是新数据，出现不一致性。

但是这种概率非常低。

而且删除缓存失败后，我们也可以做一些处理。

 

为什么是删除缓存，而不是更新缓存。

因为缓存不一定直接是数据库中的内容，有可能是多个字段计算出来的，如果每次更新都去写缓存，会导致性能消耗。

 

为什么不是先删除缓存，再更新数据库。

因为先删除缓存，如果在更新操作还没commit的时候，另外一个线程进来读取数据，缓存查不到，查数据库并放入缓存。然后第一个更新操作commit了。

导致缓存是旧数据，而数据库是新数据。且不会像前面提到的删除缓存失败那样方便做处理。

 

 

如果业务要求强一致性，则尽可能不用缓存。