使用缓存redis(cache-aside)保证数据的一致性

  1. 项目中常常会涉及到缓存的使用,但是引入缓存会带来一致性问题,需要考虑数据一致性处理。首先看一下操作逻辑,
    查询逻辑
    使用缓存redis(cache-aside)保证数据的一致性_第1张图片
    更新或者删除逻辑
    使用缓存redis(cache-aside)保证数据的一致性_第2张图片

  2. 在项目中,如果是cache-aside pattern模式,则会考虑使用先更新DB,再去删除cache的操作,原因分析如下:
    同时写数据库以及缓存数据,任何一个更新失败都会造成数据不一致。另外事务都成功,无论是先更新缓存还是再更新数据库,还是先更新数据库再更新缓存,这两种情况在并发的情况下也很容易出现双写不成功,操作时序如下图

    1. 如果使用更新模式,先更新DB再更新Cache则会带来脏数据,原因如图:
      使用缓存redis(cache-aside)保证数据的一致性_第3张图片
      假设A、B两个线程,A先更新数据库后 B再更新数据库,然后分别进行更新缓存,但是B先更新缓存成功,A后更新缓存成功,这样就导致数据库是最新的数据但是缓存中是旧的脏数据。
    2. 如果使用更新模式,先更新Cache再更新DB则会带来脏数据,原因如图:使用缓存redis(cache-aside)保证数据的一致性_第4张图片
      理由如上
    3. 如果使用删除模式,先删除cache,再去更新DB,时序图如图:使用缓存redis(cache-aside)保证数据的一致性_第5张图片
      当有写线程先失效了Cache,读线程过来未读取到,则去请求DB,此时DB还没有更新完,返回了旧数据并重新缓存,则下一次访问的时候,缓存中依旧是脏数据。
    4. 如果使用删除模式,先更新DB,再去删除Cache,是最优方案,时序图如下:使用缓存redis(cache-aside)保证数据的一致性_第6张图片
      注意:该种方案也有可能出现脏数据可能,但是概率极低,工业界推荐使用该方式进行缓存。
      何时出现脏数据?
      1. 读线程读取Cache,此时Cache刚好失效
      2. 写线程执行速度要比读线程执行快(一般情况,计算机中读是比写快很多的)
      3. 读线程最后更新Cache

这样,最后会出现脏数据。

  1. 数据一致性问题是很经典的问题,对于QPS小于4K的可以采用以上模式。以上是个人的一点拙见,如有不周,恳请指正。

你可能感兴趣的:(Java)