一、保证最终一致性的策略(Cache Policy) (一)Cache-Aside (二)补偿机制 (三)Read-Through (四)Write-Through (五)Write-Behind (六)Write-Around 二、总结 作者简介 导语| 到底是更新缓存还是删除缓存? 到底是先更新数据库,再删除缓存,还是先删除缓存,再更新数据库?本文主要介绍了在不同场景下保证数据缓存一...
这种方案适用于对数据一致性要求较低或者写请求很少的业务,当读请求没有命中缓存时,就从数据库中读,之后回写到缓存里,同时设置一个过期时间。 写请求直接更改数据库,不用操作缓存。因此当一个key没过期时,写请求更改了数据库,之后的读还是读取到旧数据。这个时候确实发生了不一致,但业务并不敏感。 方案2 先更新...
首先确认产品上对延迟性的要求,如果要求极高,且数据有可能变化,别用缓存。 通常来说,方案1就够了,笔者咨询过4,5个团队,基本都是用方案1,因为能用缓存方案,通常是读多写少场景,同时业务上对延迟具有一定的包容性。方案1没有开发成本,其实比较实用。 如果想增加更新时的即时性,就选择方案2,不过没必要做重试保证...
7 删除缓存 -> 更新数据库 -> 更新缓存 8 更新缓存 -> 更新数据库 -> 删除缓存 9 删除缓存 -> 更新数据库 -> 删除缓存 10 删除缓存 -> 更新数据库 --> 延迟比如10ms -> 删除缓存 ... 可能还有其他情况,不过,太复杂了就不列出了 注意: 在使用的方案中,更新数据库 是必须要进行,因为数据库才算真...
这样，即使某次缓存删除操作失败，消息队列也会确保最终重试成功，从而保证缓存和数据库之间的数据一致性。缓存数据一致性的终极方案：请求串行化 虽然 CacheAside 模式加上消息队列的方式能够大幅减少数据不一致的问题，但在某些极端场景下，还是有可能出现并发读写导致的缓存脏数据。为了进一步提升一致性，我们可以考虑将...
1.1 读写DB和缓存流程 读请求：命中缓存 ：直接返回Redis缓存数据，无数据库请求未命中：从数据库查询数据，并将查询结果写入Redis CUD写请求：更新数据库数据删除缓存中的数据，缓存将在下次未命中缓存时更新 1.2 数据一致性问题 缓存删除之前读取数据：假设进程 A 已成功更新 MySQL 中的值，但在删除 Redis 缓存...
4. 一致性解决方案有哪些 4.1 缓存延时双删 4.2 删除缓存重试机制 4.3 读取 binlog 异步删除 总结 一、什么是数据库与缓存一致性 数据一致性指的是: 缓存中存有数据,缓存的数据值 = 数据库中的值; 缓存中没有该数据,数据库中的值 = 最新值。
保持缓存和数据库的一致性,最简单的做法就是直接在业务中去双写或删除保持一致性;如果要跟业务解耦,就要采用订阅 binlog 或者定时刷新的方式完成。 业务耦合的一致性方案 业务中耦合更新缓存 其中一种常见的方案是更新缓存,当数据变更时更新对应缓存数据到缓存中,该行为可以在同一个业务中也可用消息中间件解耦。当查...
根据数据库与缓存的操作顺序，可分为两种方案：先更新缓存，再更新数据库。先更新数据库，再更新缓存。正常情况，二者没有差别，都能保证缓存数据与数据库数据的一致性。数据一致性问题主要发生在第一步执行成功，第二步执行失败的场景。更新数据库+更新缓存无并发场景 先更新缓存，再更新数据库 在更新缓存成功、更新...