看到好些人在写更新缓存数据代码时,先删除缓存,然后再更新数据库,而后续的操作会把数据再装载的缓存中。然而,这个是逻辑是错误的。试想,两个并发操作,一个是更新操作,另一个是查询操作,更新操作删除缓存后,查询操作没有命中缓存,先把老数据读出来后放到缓存中,然后更新操作更新了数据库 ...
针对这两点问题,一共可以分为四种方案: 先更新缓存,再更新数据库 先更新数据库,再更新缓存 先淘汰缓存,再更新数据库 先更新数据库,再淘汰缓存。 更新缓存 淘汰缓存的优缺点: 淘汰缓存 优点:操作简单,不用关心更新操作,直接将缓存中的旧值淘汰 缺点:淘汰缓存后,下一次查询无法命中缓存,需要重新读取数据库,业务复杂或者数据量大时,响应慢 更新缓存 优点:命中率高,简单key value更新缓存和淘汰 ...
2022-02-16 16:00 1 1716 推荐指数:
看到好些人在写更新缓存数据代码时,先删除缓存,然后再更新数据库,而后续的操作会把数据再装载的缓存中。然而,这个是逻辑是错误的。试想,两个并发操作,一个是更新操作,另一个是查询操作,更新操作删除缓存后,查询操作没有命中缓存,先把老数据读出来后放到缓存中,然后更新操作更新了数据库 ...
本文主要讨论这么几个问题: (1)啥时候数据库和缓存中的数据会不一致 (2)不一致优化思路 (3)如何保证数据库与缓存的一致性 一、需求缘起 上一篇《缓存架构设计细节二三事》(点击查看)引起了广泛的讨论,其中有一个结论:当数据发生变化 ...
造成数据不一致。 方案二:更新数据库,更新缓存这种缓存更新策略俗称双写,存在问题是:并发更新数据库场景 ...
一、缓存和数据库一致性问题 读取缓存步骤一般没有什么问题,但是一旦涉及到数据更新:数据库和缓存更新,就容易出现缓存(Redis)和数据库(MySQL)间的数据一致性问题。因为写和读是并发的,没法保证顺序,就会出现缓存和数据库的数据不一致的问题。 无论是“先删除缓存,再写库”,还是“先写 ...
一致性概述 在分布式系统中,可以理解为多个节点中数据的值相同. 强一致性:这种一致性级别是最符合用户直觉的,它要求系统写入什么,读出来的就是什么,用户体验好,但往往对系统的性能影响很大. 弱一致性:这种一致性级别约束了系统在写入成功后,不承诺立即可以读到写入的值 ...
本文主要讨论这么几个问题: (1)啥时候数据库和缓存中的数据会不一致 (2)不一致优化思路 (3)如何保证数据库与缓存的一致性 一、需求缘起 上一篇《缓存架构设计细节二三事》(点击查看)引起了广泛的讨论,其中有一个结论:当数据发生变化时,“先淘汰缓存,再修改数据库”这个点是大家讨论 ...
本文主要讨论这么几个问题: (1)啥时候数据库和缓存中的数据会不一致 (2)不一致优化思路 (3)如何保证数据库与缓存的一致性 一、需求缘起 上一篇《缓存架构设计细节二三事》(点击查看)引起了广泛的讨论,其中有一个结论:当数据发生变化时,“先淘汰缓存,再修改数据库”这个点是大家讨论 ...
如何保证缓存和数据库一致性,这是一个老生常谈的话题了。 但很多人对这个问题,依旧有很多疑惑: 到底是更新缓存还是删缓存? 到底选择先更新数据库,再删除缓存,还是先删除缓存,再更新数据库? 为什么要引入消息队列保证一致性? 延迟双删会有什么问题?到底要不要 ...