专业IM即时通讯软件开发,值得信赖!

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

即时通讯软件开发 云聊IM 154℃

一、数据库主从不一致

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

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

(1)主库一个写请求(主从没同步完成)

(2)从库接着一个读请求,读到了旧数据

(3)最后,主从同步完成

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

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

二、缓存与数据库不一致

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

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

(1+2)先一个写请求,淘汰缓存,写数据库

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

(6)最后,主从同步完成

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

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

三、问题分析

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

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

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

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

四、不一致优化

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

(6)主从同步

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

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

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

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

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

喜欢 (0)
仿微信聊天软件开发