在实际的项目开发中,为了提高响应的速度,通常都会将热点的数据保存到缓存中,减少数据库的查询,有效提高服务端的响应速度,但是添加缓存之后也引入缓存与数据库的一致性问题,本文将详细的讲解如何保证数据库与缓存的一致性。
在使用缓存时,通常的缓存册率有如下几种:
Cache-Aside Pattern 简称旁路缓存模式,读取缓存、读取数据库和更新缓存的操作都是在应用系统中完成,也是业务系统最常用的缓存策略。然而旁路路由策略又分为读缓存和写缓存。
说明:
写缓存的流程就比较简单,先更新数据库中的数据,然后删除旧的缓存即可。
实际的项目中运用最多的为Cache-Aside Pattern(旁路缓存)模式,在此策略下客户端先读取缓存,如果命中则返回,如果没有命中,则查询数据库并发数据写入缓存,由于数据库和缓存都需要进行修改,在高并发的场景下,可能会导致数据不一致,针对数据不一致的场景,提供了四种更新方案具体如下:
接下来具体来讲解四种方案的,以及四种方案存在的问题。
流程说明: 线程1:先更新缓存成功,但是网络原因写数据库失败,就会导致缓存是最新数据,而数据库的数据为旧数据,那缓存就是脏数据, 线程2:读取缓存中数据,而这个数据数据库中却不存在,数据库都不存在的数据,缓存并返回客户端就毫无意义了。
此方案在实际生产中不建议采用。
流程说明:
此方案在实际生产中不建议采用。
流程说明:
此方案在实际生产中不建议采用。
流程说明:
虽然存在短暂的数据不一致,但是在旁路缓存策略的时候,对于写的操作:先更新数据库,再删除缓存。
缓存延迟双删针对第三种场景的优化,具体的流程如下:
说明:先删除缓存,在更新数据库,确保数据库事务提交成功,然后休眠一段时间在删除缓存。我们都知道第三种情况是因为网络卡顿导致数据库更新失败,当网络恢复正常后,我们在执行更新数据库操作,然后再删除缓存,那么出现数据不一致的情况也就是在休眠的这短暂的时间内。
需要删除失败的key存入消息队列中,采用异步的方式来进行删除,如果删除失败的次数已经超过了最大次数,发送警告邮件,需要人工介入解决。
本文对于数据库和缓存的一致性进行详细的讲解,由于数据库和缓存一致性的场景比较复杂,每种方案都无法保证绝对的一致性,根据CAP理论我们知道缓存系统使用场景为非强一致性的场景,符合CAP中的AP,如有疑问请及时反馈。