『延迟双删』和『先修改数据库,再删除缓存』哪个方案更好?

mysql 和 redis 数据一致性方案:『延迟双删』和『先修改数据库,再删除缓存』哪个方案更好?

哪些业务场景适合『延迟双删』;又有哪些业务场景适合『先修改数据库,再删除缓存』?

哪种方案在业内更加主流?

回复
阅读 1.6k
2 个回答

延迟双删是在先修改数据库再删除缓存的情况下,为了使缓存与数据库达到最终一致,再进行一次延迟删除,称为延迟双删

由于在修改数据库之前,此时缓存可能刚好失效,另一个读取请求进来之后发现缓存中不存在,就会从数据库读取数据,假设此时读取完但还没放到缓存中,这时修改数据库、删除缓存的操作执行先完成,那么读取完放到缓存中的数据就是旧数据,与数据库中的数据不一致

延时双删只是增加了一次redis的key的操作,消耗基本可以忽略不计!建议用延时双删!

以下是使用场景区别:
1.先改数据库再改缓存:对接口速度有要求,确保修改数据能在最短时间内同步的情况使用,以为它比延迟双删少了一次耗时计算和key操作。
使用场景如 :任务部门操作同步延迟、常用模板生效时间延迟、监控人员坐标位置信息最快时间展示等

2.延时双删:可以接受一定延迟,并且一致性要求比较强的时候使用延时双删,延时双删,只是降低了同步不及时概率,并不是强一致性,延时时间是一个预估值,不能确保 mysql 和 redis 数据在这个时间段内都实时同步或持久化成功了
使用场景 如:基础数据平台提供数据给其他系统使用,要求数据及时同步,并且这个接口不会被频繁调用

撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
推荐问题
宣传栏