|
|
51CTO旗下网站
|
|
移动端
创建专栏

缓存与数据库不一致,咋办?

缓存与数据库的操作时序,不管是《Cache Aside Pattern》中的方案,还是《究竟先操作缓存,还是数据库?》中的方案,都会遇到缓存与数据库不一致的问题。今天聊聊这个问题。

作者:58沈剑|2018-07-15 08:18

缓存与数据库的操作时序,不管是《Cache Aside Pattern》中的方案,还是《究竟先操作缓存,还是数据库?》中的方案,都会遇到缓存与数据库不一致的问题。今天聊聊这个问题。

缓存与数据库不一致,咋办?

一、数据库主从不一致

先回顾下,无缓存时,数据库主从不一致问题。

如上图,发生的场景是,写后立刻读:

  • 主库一个写请求(主从没同步完成)
  • 从库接着一个读请求,读到了旧数据
  • 最后,主从同步完成

导致的结果是:主动同步完成之前,会读取到旧数据。

可以看到,主从不一致的影响时间很短,在主从同步完成后,就会读到新数据。

二、缓存与数据库不一致

再看,引入缓存后,缓存和数据库不一致问题。

如上图,发生的场景也是,写后立刻读:

  • (1+2)先一个写请求,淘汰缓存,写数据库
  • (3+4+5)接着立刻一个读请求,读缓存,cache miss,读从库,写缓存放入数据,以便后续的读能够cache hit(主从同步没有完成,缓存中放入了旧数据)
  • (6)最后,主从同步完成

导致的结果是:旧数据放入缓存,即使主从同步完成,后续仍然会从缓存一直读取到旧数据。

可以看到,加入缓存后,导致的不一致影响时间会很长,并且最终也不会达到一致。

三、问题分析

可以看到,这里提到的缓存与数据库数据不一致,根本上是由数据库主从不一致引起的。当主库上发生写操作之后,从库binlog同步的时间间隔内,读请求,可能导致有旧数据入缓存。

假如主从不一致没法彻底解决,引入缓存之后,binlog同步时间间隔内,也无法避免读旧数据。

但是,有没有办法做到,即使引入缓存,不一致不会比“不引入缓存”更糟呢?这是更为实际的优化目标。

思路转化为:在从库同步完成之后,如果有旧数据入缓存,应该及时把这个旧数据淘汰掉。

四、不一致优化

如上图所述,在并发读写导致缓存中读入了脏数据之后:

  • (6)主从同步
  • (7)通过工具订阅从库的binlog,这里能够最准确的知道,从库数据同步完成的时间

画外音:本图画的订阅工具是DTS,可以是cannal,也可以自己订阅和分析binlog

  • (8)从库执行完写操作,向缓存再次发起删除,淘汰这段时间内可能写入缓存的旧数据

如此这般,至少能够保证,引入缓存之后,主从不一致,不会比没有引入缓存更坏。

画外音:即使引入缓存,也只有一个很小的时间间隔,可能读到旧数据。

五、结尾

问:如何完全避免,主从同步时间差,数据的一致性?

答:详见《数据库主从不一致,怎么解?》。

问:该方案,只能优化,并发读写情况下,缓存与数据库一致性问题。如果,缓存与数据库两次操作,原子性被破坏(例如:修改数据库成功,淘汰缓存失败,导致的数据不一致),如何优化数据的一致性呢?

答:详见《究竟先操作缓存,还是数据库?》。

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

【编辑推荐】

  1. 数据科学大Battle,你站Python还是R
  2. 图解 HTTP 的缓存机制 | 实用 HTTP
  3. GDPR通用数据保护条例-要点总结
  4. 究竟先操作缓存,还是数据库?
  5. Cache Aside Pattern(缓存模式)解析
【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢