方案1:先更新数据库,再删除redis 更新时,先更新数据库的数据,然后删除redis中的旧数据。 读写场景: 场景一:缓存X,数据库X。A更新时,B读取A更新数据库 数据库A,缓存XB读取缓存 读取缓存XA删除缓存 数据库A,无缓存 其他线程读 数据库A,缓存A结果:出现短时数据不一致问题,随后数据保持一致 场景二:无缓存,数据...
3.1 先删除缓存,再更新数据库 3.2 先更新数据库,再让缓存失效 3.3 只更新缓存,由缓存自己同步更新数据库(Read/Write Through Pattern) 3.4 只更新缓存,由缓存自己异步更新数据库(Write Behind Cache Pattern) 总结 问题 面试当中总会被问题这么一个问题:如何保证 Redis 缓存和数据库一致性? 但依旧有很多的疑问: ...
Write behind跟Read-Through/Write-Through有相似的地方,都是由Cache Provider来负责缓存和数据库的读写。 它两又有个很大的不同: Read/Write Through是同步更新缓存和数据的,Write Behind则是只更新缓存,不直接更新数据库,通过批量异步的方式来更新数据库。 这种方式下,缓存和数据库的一致性不强,对一致性要求高的...
原因是当数据库更新成功后,缓存更新失败,出现数据库为最新值,缓存为旧值。导致后续的所有的读请求,在缓存未过期或缓存未重新正确更新的情况下,会一直保持了数据的完全不一致! image-20240916004758430 该方案就算在更新数据库、更新缓存都成功的情况下,还是会存在并发引发的一致性问题,如下图所示(点击图片查看大图): ...
首先要明白redis是一个数据库,redis是一个内存数据库(后端调用的,缓解sql数据库压力的,像双十一直接大量查询进入数据库,数据库会直接崩溃,所以在数据库前面先拦一下,先在缓存里查询,缓解压力), 所有数据基本上都存在于内存当中,会定时以追加或者快照的方式刷新到硬盘中. 由于redis是一个内存数据库, 所以读取写入的...
第一步成功,第二步失败,cache中是旧数据,数据库是新数据,数据不一致,解决办法:为确保缓存删除成功,用“重试机制”,即当删除cache失败后,返回错误,由业务代码再次重试,直至删除OK。 【结论】 总体而言,虽然方案二导致数据不一致的可能性更大,但在业务中,无论是淘汰缓存还是更新数据库,我们都需要确保它们真正完成了...