qidao123.com技术社区-IT企服评测·应用市场

标题: 架构思维：缓存层场景实战_读缓存（下） [打印本页]
作者: 东湖之滨    时间: 2025-4-29 18:53
标题: 架构思维：缓存层场景实战_读缓存（下）

Pre

Java避坑案例 - 高并发场景下的分布式缓存计谋
Redis - 缓存设计深度剖析：穿透、并发、雪崩与热点计谋
深入理解分布式技术 - 先更新数据库，还是先更新缓存
架构思维：读缓存 - 减少数据库读利用压力
业务场景

某系统商品详情页因叠加保举、成交记录、优惠活动等功能，导致每次访问需实验数十条SQL，平均响应时间从3.61秒恶化至15.53秒。初期思量本地缓存（如Guava），但测算发现5万商品数据需750GB内存（30节点×25GB），成本过高。最终采用分布式缓存方案，将数据集中存储（如Redis），所有服务节点共享同一缓存源，避免冗余存储，显著提拔访问速率至毫秒级，同时降低硬件成本。优化后，异步加载非核心数据（如成交记录）进一步减轻及时查询压力。
技术选型完成后，开始思量缓存的一些详细问题，先从缓存何时存储数据入手
缓存存储数据的时机与常见问题办理方案

1. 缓存读取与存储逻辑

2. 高并发下的缓存问题及办理方案

这种逻辑唯一麻烦的地方是，当用户发来大量的并发请求时，它们会发现缓存中没有数据，那么所有请求会同时挤在第2）步，此时如果这些请叱责部从数据库读取数据，就会让数据库崩溃。
数据库的崩溃可以分为3种情况。

故，总结如下：

3. 缓存预热（减少冷启动问题）

上面这些逻辑都是在确保查询数据的请求已经过来后如何适本地处理处罚，如果缓存数据找不到，再去数据库查询，最终是要占用服务器额外资源的。那么最理想的就是在用户请求过来之前把数据都缓存到Redis中。这就是缓存预热。
其详细做法就是在深夜无人访问或访问量小的时候，将预热的数据生存到缓存中，这样流量大的时候，用户查询就无须再从数据库读取数据了，将大大减小数据读取压力。
故，总结如下：

缓存更新计谋（双写问题）

关于缓存何时存数据的问题就讨论完了，接下来开始讨论更新缓存的问题，这部分内容因涉及双写（缓存+数据库），以是会花费一些篇幅。

在缓存更新时，我们必要思量 数据库与缓存的一致性，同时避免 并发问题 和 性能瓶颈。以下是 5种常见的缓存更新计谋，分析它们的优缺点，并给出保举方案。
1. 先更新缓存，再更新数据库（不保举）

对于这个组合，会碰到这种情况：假设第二步更新数据库失败了，要求回滚缓存的更新，这时该怎么办呢？Redis不支持事故回滚，除非采用手工回滚的方式，先生存原有数据，然后再将缓存更新回原来的数据，这种办理方案有些缺陷。
这里简单举个例子。
1）原来缓存中的值是a，两个线程同时更新库存。
2）线程A将缓存中的值更新成b，且生存了原来的值a，然后更新数据库。
3）线程B将缓存中的值更新成c，且生存了原来的值b，然后更新数据库。
4）线程A更新数据库时失败了，它必须回滚，那如今缓存中的值更新成什么呢？理论上应该更新成c，因为数据库中的值是c，但是，线程A里面无从获得c这个值。
如果在线程A更新缓存与数据库的整个过程中，先把缓存及数据库都锁上，确保别的线程不能更新，是否可行？固然是可行的。但是其他线程能不能读取？
假设线程A更新数据库失败回滚缓存时，线程C也加入进来，它必要先读取缓存中的值，这时又返回什么值？
看到这个场景，是不是有点儿认识？不错，这就是典型的事故隔离级别场景。以是就不保举这个组合，因为此处只是必要使用一下缓存，而这个组合就要思量事故隔离级别的一些逻辑，成本太大。接着思量别的组合。
故， 总结如下：
流程：
     问题：

结论：❌ 不保举，容易导致数据不一致。
2. 先删除缓存，再更新数据库（不保举）

使用这种方案，即使更新数据库失败了也不必要回滚缓存。这种做法虽然奥妙规避了失败回滚的问题，却引出了两个更大的问题。
1）假设线程A先删除缓存，再更新数据库。在线程A完成更新数据库之前，后实验的线程B反而超前完成了利用，读取Key发现没有数据后，将数据库中的旧值存放到了缓存中。线程A在线程B都完成后再更新数据库，这样就会出现缓存（旧值）与数据库的值（新值）不一致的问题。
2）为了办理一致性问题，可以让线程A给Key加锁，因为写利用特别耗时，这种处理处罚方法会导致大量的读请求卡在锁中。
以上描述的是典型的高可用和一致性难以两全的问题，如果再加上分区容错就是CAP（一致性Consistency、可用性Availability、分区容错性Partition Tolerance）了，这里不睁开讨论，接下来继续讨论另外3种组合
故， 总结如下：
流程：
     问题：

办理方案：

结论：❌ 不保举，容易导致缓存与数据库不一致。
3. 先更新数据库，再更新缓存（不保举）

对于组合3，同样必要思量两个问题。
1）假设第一步（更新数据库）乐成，第二步（更新缓存）失败了怎么办？
因为缓存不是主流程，数据库才是，以是不会因为更新缓存失败而回滚第一步对数据库的更新。此时一样平常采取的做法是重试机制，但重试机制如果存在延时还是会出现数据库与缓存不一致的情况，不利益理。
2）假设两个线程同时更新同一个数据，线程A先完成了第一步，线程B先完成了第二步怎么办？线程A把值更新成a，线程B把值更新成b，此时数据库中的最新值是b，因为线程A先完成了第一步，后完成第二步，以是缓存中的最新值是a，数据库与缓存的值还是不一致，这个逻辑还是有问题的。
因此，也不建议采用这个组合
故， 总结如下：
流程：
     问题：

结论：❌ 不保举，仍大概不一致。
4. 先更新数据库，再删除缓存（Cache-Aside模式 保举⭐）

针对组合4，先看看它能不能办理组合3的第二个问题。
假设两个线程同时更新同一个数据，线程A先完成第一步，线程B先完成第二步怎么办？
线程A把值更新成a，线程B把值更新成b，此时数据库中的最新值是b，因为线程A先完成了第一步，以是第二步谁先完成已经不告急了，因为都是直接删除缓存数据。这个问题办理了。
那么，它能办理组合3的第一个问题吗？假设第一步乐成，第二步失败了怎么办？
这种情况的出现概率与组合3相比明显低不少，因为删除比更新容易多了。虽然这个组合方案不完美，但出现一致性问题的概率较低。
故， 总结如下：
流程：
     优点：

问题：

办理方案：

结论：✅ 保举，相比前3种方案更可靠。
5. 延长双删（先删缓存→更新DB→再删缓存）（最佳实践⭐）

除了组合3会碰到的问题，组合4还会碰到别的问题吗？
是的。假设线程A要更新数据，先完成第一步更新数据库，在线程A删除缓存之前，线程B要访问缓存，那么取得的就是旧数据。这是一个小小的缺陷。
那么，以上问题有办法办理吗？
另有一个方案，就是先删除缓存，再更新数据库，再删除缓存。这个方案其实和先更新数据库，再删除缓存差不多，因为还是会出现类似的问题：假设线程A要更新数据库，先删除了缓存，这一瞬间线程C要读缓存，先把数据迁移到缓存；然后线程A完成了更新数据库的利用，这一瞬间线程B也要访问缓存，此时它访问到的就是线程C放到缓存里面的旧数据。
不外组合5出现类似问题的概率更低，因为要刚好有3个线程配合才会出现问题（比先更新数据库，再删除缓存的方案多了一个必要配合的线程）。
但是相比于组合4，组合5规避了第二步删除缓存失败的问题——组合5是先删除缓存，再更新数据库，假设它的第三步“再删除缓存”失败了，也不要紧，因为缓存已经删除了。
其实没有一个组合是完美的，它们都有读到脏数据（这里指旧数据）的大概性，只不外概率差别。根据以上分析，组合5相对来说是比力好的选择。
不外这个组合也有一些问题要思量，详细如下。

   任何一个方案都不是完美的，但如果剩下1%的问题必要花好几倍的代价去办理，从技术上来讲得不偿失，这就要求架构师去说服业务方，去平衡技术的成本和收益。
  故， 总结如下：
流程：
     优点：

问题：

适用场景：

结论：✅ 最佳实践，比方案4更可靠。 延长双删通过两次删除利用创建安全窗口，在工程实践上实现了性能与一致性的最佳平衡，是分布式系统缓存更新的首选方案 .
总结：如何选择缓存更新计谋

方案描述一致性保举度1️⃣ 先更新缓存，再更新DB易回滚问题❌ 差❌ 不保举2️⃣ 先删缓存，再更新DB旧数据问题❌ 差❌ 不保举3️⃣ 先更新DB，再更新缓存并发问题⚠️ 一样平常❌ 不保举4️⃣ 先更新DB，再删缓存较可靠✅ 较好⭐ 保举5️⃣ 延长双删最可靠✅ 最佳⭐⭐⭐ 最佳
最终建议


没有完美方案，但 方案4和5 在大多数场景下能平衡 性能与一致性。
缓存高可用设计核心要点与监控方案

1、缓存高可用设计的5大核心要点

保举架构：

2、缓存监控关键指标与工具

3、总结


最终建议：根据业务规模选择Redis Sentinel或Cluster，并配套监控诉警体系，确保缓存稳固支撑业务高峰。


免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 qidao123.com技术社区-IT企服评测·应用市场 (https://dis.qidao123.com/) Powered by Discuz! X3.4