我们在日常工作中经常会遇到要求缓存和数据库强一致性的问题,我们平常的做法是,确保数据库插入成功,然后再更新缓存,但有时候数据库插入成功后,缓存出现问题或者缓存系统挂了,这时候请求会直接访问数据库最新的数据。但是当缓存恢复的时候,我们的并发请求又会访问到以前旧的缓存数据,这时候就会出现不一致问题。如果我们的业务系统对一致性要求不高,那么可以这么做,但是如果必须是强一致性,那么这个方案是有明显漏洞的。
有的朋友可能会说,当缓存恢复的时候直接清空缓存就可以了,然后重新加载一遍,这样有二个问题,第一个是我们的缓存数据有一部分其实是不经常变动的,全部清空再加载效率就非常低了。
方案一
数据写入端:
注:同样我们是同时写数据库和缓存,但是在写缓存的时候会判断写入是否成功,如果写入出错,我们将key和更新状态值插入到数据库状态表中,同时关闭前端访问缓存的开关。
数据读入端:
注:客户端在读数据的时候,要先判断一下当然开关是否打开,如果打开则读取缓存,如果关闭则直接访问数据库。关于判断缓存开关的问题,可以不用每次读库,而可以事先缓存到本地。
缓存恢复端:
注:后台有一个守护定时任务,每隔一定时间来检测缓存系统是否可用,如果可用则从状态表中读取key值和更新状态位,然后打开缓存读取开关,这样前端数据读取端则能够从缓存读取最新数据。
总结:
这方案的前提是当前并发量并不是非常大的情况,试想如果当前并发非常大,同时缓存又出了问题,这时候整个请求就穿透到了数据库层造成严重问题。
那么我之前的初步想法是将这个流程封装为中间件,根据不同库配置不同的数据源,客户端只需要直接请求中间件即可。但此方案不适合分库分表的场景!在某种情况下是有局限性的!这个方案更多是为大家提供一种思路!
方案二
当缓存不可用时,在第一时间不对数据库服务发起请求,在需要的时候异步填充缓存(优先热点缓存),然后我们将前端的请求直接返回失败,也就是快速返回失败,直到缓存恢复并且热点缓存填充完毕。
注:在某些情况下,这种方法意义不大,但当系统的一部分发生故障时可以确保系统仍然可用的一种方式,让请求快速失败,确保不占用资源,也避免了级联下游服务的故障。
作者:Alukar
链接:https://www.jianshu.com/p/c0411c296b96
共同学习,写下你的评论
评论加载中...
作者其他优质文章