缓存数据一致性

最新推荐文章于 2025-08-29 17:53:24 发布
原创 最新推荐文章于 2025-08-29 17:53:24 发布 · 333 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

主要参考自 美团点评 张韩文章: https://maimai.cn/article/detail?fid=1057432698&efid=vnXzd0cl0pDwUW6f6iMpGA&from=groupmessage

为什么会有缓存数据一致性问题（Why）

数据变更

更新完数据库，是更新缓存呢，还是删除缓存。

又或者是先删除缓存，再更新数据库？

总结为下面四种更新策略：

更新策略：

  1. 先更新数据库，再更新缓存
  2. 先删除缓存，再更新数据库
  3. 先更新数据库，再删除缓存

  4. 先更新缓存，再更新数据库（更新缓存成功，更新数据库失败，导致业务数据不一致。直接淘汰。）                                 

以上四种策略分析见脑图如下：

多级缓存和数据一致性问题
m0_61716416的博客
03-26 1188
是一种分层的数据缓存策略，通过在不同层级（如本地、分布式、数据库）存储数据副本，结合各层缓存的访问速度和容量特性，优化系统的性能和资源利用率。使用发布订阅模型（如 Redis Pub/Sub），当数据变更时，广播消息通知所有节点失效本地缓存。为本地缓存设置较短的 TTL（如 30 秒），通过牺牲少量性能换取更高一致性。，减少对远端存储（如数据库）的直接访问，从而降低延迟、提升吞吐量。（以下内容为之前回答的简要总结，完整版可参考上文）（以下内容为之前回答的简要总结，完整版可参考上文）
Redis+Caffeine 多级缓存数据一致性解决方案
Y_eatMeat的博客
12-03 2418
Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。当有新消息通过 publish 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端。Redis的订阅发布功能与传统的消息中间件（如：RabbitMQ）相比，相对轻量一些，针对数据准确和安全性要求没有那么高的场景可以直接使用。本文主要讲解了在使用Redis和Caffeine多级缓存时使用Redis的发布订阅模式来保证两级缓存的数据一致性。
缓存与数据库一致性保证
03-01
（1）啥时候数据库和缓存中的数据会不一致 （2）不一致优化思路 （3）如何保证数据库与缓存的一致性
缓存与数据库一致性
weixin_33935505的博客
08-30 166
1.使用缓存的场景 缓存是提高系统读性能的常用技术，尤其对于读多写少的应用场景，使用缓存可以极大的提高系统的性能 例子：查询用户的存款： select money from user where uid = YYY; 为了优化该查询功能，我们可以在缓存中建立uid->money的键值对。 减少数据库的查询压力。         2. 读操作流程 目前数据库和缓存中都有存储数据，当...
一文带你了解缓存和数据库一致性问题
kfashfasf的博客
08-29 1027
缓存作为持久化存储（如数据库）的辅助存在，毕竟属于两套系统。理想情况下是缓存数据与数据库中数据完全一致，但是业务最常使用的旁路缓存架构下，在一些分布式或者高并发的场景中，可能会出现缓存不一致的情况。在分布式系统中，数据一致性是一个核心问题。根据系统的设计与需求，可以选择实时强一致性(Strong Consistency)或最终一致性(Eventual Consistency)。
课时65 缓存-分布式锁-缓存一致性解决
weixin_44543578的博客
05-20 255
无论是双写模式还是失效模式，都会导致缓存的不一致问题。即多个实例同时更新会出事。怎么办？ 1、如果是用户维度数据（订单数据、用户数据），这种并发几率非常小，不用考虑这个问题，缓存数据加上过期时间，每隔一段时间触发读的主动更新即可 2、如果是菜单，商品介绍等基础数据，也可以去使用canal订阅binlog的方式 3、缓存数据+过期时间也足够解决大部分对于缓存的需求 4、通过加锁保证并发读写，写写时候按顺序排好队，读读无所谓。所以适合使用读写锁。（业务不关心脏数据，允许临时脏数据可忽略） 总结 ·我们能放入缓存
缓存数据的一致性
CloverYou的博客
01-06 455
缓存数据的一致性 读所有的数据，首先去缓存中获取，缓存中没有就去读数据库，最后在缓存中放一份。如果该数据在数据库中发生改变，那么缓存里面的数据如何和数据库保持一致？解决这个问题，目前有两个用的非常多的场景： 双写模式 失效模式 双写模式 修改数据库的数据后再修改缓存中的数据 但又引出了一个问题，那就是当有并发时，线程一将数据库的值改为「一号」然后立刻将这个值保存到缓存，而保存过程中遇到了种种原因，如网络波动，导致了数据延迟抵达缓存服务器，而此时线程二已经将数据库数据改为「二号」然后将数据保存到缓存，线
缓存 -- 缓存数据的一致性
yinni11的博客
09-27 377
用空间换时间。使用缓存后，运行时间更短了！ 例子：    读取上图中的收益详情：138.24     比较从数据库读或者从缓存中读时的时间。    当一个语句的查询时间超过300毫秒的时候，就要优化语句了。    用mybatis实现   收益的实体类为：    Mapper接口如下： 业务代码如下： 注入数据库的Dao层 private ProfitDetail...
2005,我们“芯芯”相印——双核心CPU缓存数据一致性浅析.pdf
09-24
双核心CPU缓存数据一致性浅析 本文主要讨论双核心CPU缓存数据一致性问题。随着双核心CPU的出现，缓存数据一致性问题变得越来越重要。双核心CPU的设计主要有两种：独立缓存设计和共享缓存设计。独立缓存设计是指每个...
Redis缓存数据一致性解决方案分析.docx
10-26
Redis 缓存数据一致性解决方案分析 在本文中，我们将探讨 Redis 缓存数据的一致性解决方案。Redis 作为一个非关系型数据库，已经被应用在各种高性能的业务场景中。然而，在实际的使用过程中，大多数也是用在一些...
多级缓存架构下的数据一致性保障
qq_42773076的博客
08-22 872
多级缓存数据一致性解决方案 核心问题与风险 多级缓存架构中，数据不一致主要源于数据副本同步延迟和并发更新竞争，可能导致库存超卖、金额显示错误等严重业务问题。 关键设计原则 一致性分级：根据业务需求选择强一致性、最终一致性或弱一致性 更新策略明确：确定更新触发者、时机和失败处理方案 并发控制：通过锁机制或版本号避免更新冲突 主流解决方案 1. 缓存更新策略 缓存旁路模式：读时加载，写时失效（适合读多写少场景） 写透模式：通过缓存中间件同步更新数据库（强一致性场景） 写回模式：异步批量更新数据库（高性能写场景）
Java的多线程机制:缓存一致性和CAS
weixin_34025151的博客
11-05 383
2019独角兽企业重金招聘Python工程师标准>>> ...
Redis（六）：数据库和缓存双写一致性方案解析
scofen的博客
08-28 1489
一般来说，对于一个新的业务，一般会经历这几个阶段： 阶段1：单库阶段 读写流量都比较小，这个时候所有的读写操作都在主库就ok了 这个时候，从库可能只是用来灾备风险分析：从数据一致性角度来说没有风险，全走主库美滋滋~ 阶段2：多库阶段 阶段2.1： 单库扛不住了，这个时候就会考虑到分库分表了，通过增加数据库的方式，把单库的QPS降下来风险分析：从数据一致性角度来说没有风险，全走主库依然美...
缓存与数据库的一致性
chengbinbbs的专栏
04-03 2170
什么是缓存？ 缓存就是数据交换的缓冲区，针对服务对象的不同（本质就是不同的硬件）都可以构建缓存。 目的是，把读写速度慢的介质的数据保存在读写速度快的介质中，从而提高读写速度，减少时间消耗。 例如： CPU 高速缓存 ：高速缓存的读写速度远高于内存。 CPU 读数据时，如果在高速缓存中找到所需数据，就不需要读内存 CPU 写数据时，先写到高速缓存，再回写到内存。 磁盘缓存：磁盘缓存其实就...
缓存数据一致性-解决方案
m0_56466015的博客
03-10 6885
缓存数据一致性-解决方案
缓存数据一致性问题
wandoubi的博客
04-04 400
Redis 缓存与数据库的 数据不一致 缓存与数据库的“一致性” 包含以下两种情况： 缓存中有数据，缓存的数据值需要和数据库中的值相同； 缓存中本身没有数据，那么数据库中的值必须是最新值。 对于读写缓存来说，如果要对数据进行增删改，就需要在缓存中进行，同时还要根据采取的写回策略，决定是否同步写回到数据库中。 同步直写策略：写缓存时，也同步写数据库，缓存和数据库中的数据一致； 异步写回策略：写缓存时不同步写数据库，等到数据从缓存中淘汰时，再写回数据库。使用这种策略时，如果数据还没有写回数据库，缓存就发生
缓存和数据库数据一致性
lebronchen的博客
08-27 1356
1、产生缓存和数据库数据一致性问题的问题 当我们数据库压力大的时候可以对数据库做读写分离，主库负责写操作，从库负责读操作，主从数据库之间采用二进制日志文件来同步数据。 还有另一种解决方案是使用缓存，通常我们使用缓存的姿势是查询直接从缓存中取，缓存中没有则去数据库取，数据库取到结果之后再塞到缓存中去。如果有修改操作，则删除缓存，并且查询一次结果塞到缓存中。 上面两个方案都是为了解决数据库压力太...
缓存和数据库数据一致性解析
weixin_43241803的博客
06-09 456
缓存数据库 更新，删除一致性解析
关于缓存数据一致性的解决方案
一起交流，一起进步
01-31 2317
解决缓存和数据库数据不一致的问题
电商系统保证数据库与缓存数据一致性
最新发布
10-28
电商系统中保证数据库与缓存数据一致性可从多个方面着手，以下是一些常见的解决方案： ### 最终一致性策略 多数场景可接受短暂不一致，可通过重试、定时任务（如每天全量同步）修复数据不一致问题。同时，设置合理的 TTL（生存时间），自动淘汰旧数据，还需监控缓存命中率、数据库与 Redis 的数据差异，及时发现不一致并处理[^2]。 ### 常见一致性方案 1. **先更新 DB，再删除缓存（Cache - Aside）**：这是最常用的方案，能实现最终一致，性能高且复杂度低。不过在并发、异常、网络延迟下，可能出现时序错乱，例如线程 A 更新数据库成功后，删除缓存失败（网络超时），此时线程 B 查询缓存会命中旧数据，导致数据库已更新，缓存仍是旧值的不一致情况[^3]。 2. **延迟双删（Delayed Double Delete）**：删除两次缓存，能防止并发问题，一致性较好，性能和复杂度处于中等水平[^3]。 3. **先删缓存，再更新 DB（Write - Behind）**：此方案风险高，不推荐使用，一致性差，性能高但复杂度低[^3]。 4. **基于 Binlog 的异步更新（如 Canal）**：异步监听数据库变更，实现最终一致，性能和复杂度都较高[^3]。 5. **分布式事务（如 Seata）**：能实现强一致，但性能差，复杂度高[^3]。 ### 针对不同并发情况的处理 对于并发几率很小的数据（如个人维度的订单数据、用户数据等），很少会发生缓存不一致，可以给缓存数据加上过期时间，每隔一段时间触发读的主动更新。就算并发很高，如果业务上能容忍短时间的缓存数据不一致（如商品名称，商品分类菜单等），给缓存加上过期时间依然可以解决大部分业务对于缓存的要求[^4]。 ### 推荐方案 推荐采用 Cache - Aside + 主动失效的方案，这是生产级常用方案[^3]。 以下是一个简单的 Java 示例代码，展示先更新 DB，再删除缓存的基本实现： ```java import java.util.HashMap; import java.util.Map; // 模拟数据库 class Database { private Map<String, String> data = new HashMap<>(); public void updateData(String key, String value) { data.put(key, value); } public String getData(String key) { return data.get(key); } } // 模拟缓存 class Cache { private Map<String, String> cacheData = new HashMap<>(); public void deleteCache(String key) { cacheData.remove(key); } public String getCache(String key) { return cacheData.get(key); } public void setCache(String key, String value) { cacheData.put(key, value); } } public class CacheDatabaseConsistency { private Database database = new Database(); private Cache cache = new Cache(); public void updateDataAndDeleteCache(String key, String value) { // 先更新数据库 database.updateData(key, value); // 再删除缓存 cache.deleteCache(key); } public String getData(String key) { String cacheValue = cache.getCache(key); if (cacheValue != null) { return cacheValue; } // 缓存未命中，从数据库获取 String dbValue = database.getData(key); if (dbValue != null) { // 将数据存入缓存 cache.setCache(key, dbValue); } return dbValue; } public static void main(String[] args) { CacheDatabaseConsistency consistency = new CacheDatabaseConsistency(); consistency.updateDataAndDeleteCache("product1", "New Product Name"); String data = consistency.getData("product1"); System.out.println(data); } } ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值