一、保证最终一致性的策略(Cache Policy) (一)Cache-Aside (二)补偿机制 (三)Read-Through (四)Write-Through (五)Write-Behind (六)Write-Around 二、总结 作者简介 导语| 到底是更新缓存还是删除缓存? 到底是先更新数据库,再删除缓存,还是先删除缓存,再更新数据库?本文主要介绍了在不同场景下保证数据缓存一...
这种方案适用于对数据一致性要求较低或者写请求很少的业务,当读请求没有命中缓存时,就从数据库中读,之后回写到缓存里,同时设置一个过期时间。 写请求直接更改数据库,不用操作缓存。因此当一个key没过期时,写请求更改了数据库,之后的读还是读取到旧数据。这个时候确实发生了不一致,但业务并不敏感。 方案2 先更新...
7 删除缓存 -> 更新数据库 -> 更新缓存 8 更新缓存 -> 更新数据库 -> 删除缓存 9 删除缓存 -> 更新数据库 -> 删除缓存 10 删除缓存 -> 更新数据库 --> 延迟比如10ms -> 删除缓存 ... 可能还有其他情况,不过,太复杂了就不列出了 注意: 在使用的方案中,更新数据库 是必须要进行,因为数据库才算真...
1.1 读写DB和缓存流程 读请求：命中缓存 ：直接返回Redis缓存数据，无数据库请求未命中：从数据库查询数据，并将查询结果写入Redis CUD写请求：更新数据库数据删除缓存中的数据，缓存将在下次未命中缓存时更新 1.2 数据一致性问题 缓存删除之前读取数据：假设进程 A 已成功更新 MySQL 中的值，但在删除 Redis 缓存...
Redis 缓存和数据库数据的一致性问题解决方案 方案一:先更新Redis缓存,再更新数据库 这个方案一般不考虑。 原因是当数据同步时,更新 Redis 缓存成功,但更新数据库出现异常时,会导致 Redis 缓存数据与数据库数据完全不一致,而且这很难察觉,因为 Redis 缓存中的数据一直都存在。
根据数据库与缓存的操作顺序，可分为两种方案：先更新缓存，再更新数据库。先更新数据库，再更新缓存。正常情况，二者没有差别，都能保证缓存数据与数据库数据的一致性。数据一致性问题主要发生在第一步执行成功，第二步执行失败的场景。更新数据库+更新缓存无并发场景 先更新缓存，再更新数据库 在更新缓存成功、更新...
方案一：先写缓存，再写数据库 场景：当请求A和请求B同时操作同一条数据，则可能出现如下现象。请求A...
在使用redis的时候,前面介绍了,由于操作数据库和操作redis缓存不是一个原子操作,且还会存在多个CPU之间并行执行的情况,所以就会有一个线程在操作数据库和缓存的时间节点之间,另外一个线程也在执行操作数据库和缓存,这样就会导致数据可以与缓存之间会存在数据不一致的情况。
如果数据库写入成功,而Redis写入失败,那么数据库中就是最新值,缓存中为旧值,出现数据不一致,如果此时查询数据的时候就会查询到旧值,从而导致业务数据异常。 先写缓存再写数据库 另外一种方案,如果先更新Redis再更新数据库,但是Redis缓存更新成功了,数据库更新失败了,那么就说明缓存中为业务最新值,而数据库中是业务旧...
先更新数据库,再更新缓存 先删除缓存,再更新数据库 先更新数据库,再删除缓存 一些一致性要求不高的数据,如点赞数等,可以先更新缓存,然后再定时同步到数据库。而在其它情况下,我们通常会等数据库操作成功,再操作缓存。 下面主要介绍更新数据库成功后,更新缓存和删除缓存这两个操作的区别和改进方案。