Redis----缓存设计、旁路缓存优化

原创 于 2025-06-07 21:14:34 发布 · 4.5k 阅读 · 22 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#缓存 #redis #数据库

一.缓存三大问题

1.缓存雪崩

大量缓存数据在同一时间过期，那么此时用户的大量请求就会直接访问数据库，数据库的并发能力有限，可能会宕机导致连锁反应，造成整个系统的崩溃.

1.1解决方案

避免数据同时过期:给key的TTL添加较小的随机值

设置缓存不过期: 后台更新缓存数据

2.缓存击穿

某个高并发且缓存重建业务比较复杂的key突然失效，大量请求冲击数据库且多个线程尝试重建缓存

2.1解决方案

互斥锁:基于sexnx命令的互斥锁，在尝试缓存重建前先获取互斥锁，获取到了再进行缓存重建的工作，保证只有一个线程进行缓存重建的操作，避免浪费系统资源

逻辑过期+缓存预热:提前将热点数据添加到Redis中，不设置真正的过期时间，利用额外字段保存逻辑过期时间，查到数据时判断是否过期.若过期则先返回旧数据，并开启一个子线程获取互斥锁进行异步重建

3.缓存穿透

用户要访问的数据本身在数据库中就不存在，那么缓存中必然也不会存在.这样的请求，首先会访问缓存，缓存中不存在对应的数据必然会访问数据库，而数据库中也没有数据，无法进行缓存重建，那么后续的请求都会重复该流程，请求最终都会到达数据库，无法承受过高的并发导致宕机。缓存穿透一般是数据误删或恶意攻击导致

3.1解决方案

参数校验:提前对参数格式做特殊要求，当请求到来时先进行参数校验，不合法的参数直接拒绝访问

缓存空值:对于缓存中没有，数据库也查不到的数据向Redis中缓存一个空值，避免后续相同的请求再次访问到数据库;缺点:无法处理大量不同非法请求的情况

布隆过滤器:保存数据时，利用哈希函数计算key多个位置，将相应的位置都设置为1，查询元素时同样利用哈希元素进行计算，如果计算出的位置都是1，则认为该元素肯能存在，继续执行后续操作，否则认为元素一定不存在拒绝访问；可能存在元素误删问题

二.缓存更新策略

Cache Aside(旁路缓存) 适合读多写少的场景

写策略:先更新数据库中的数据，再删除缓存中的

直接删除缓存的方式，若每次修改数据都更新缓存则可能会产生很多无效更新，有数据修改时直接删除缓存，有新的读需求时从数据库中查最新的数据重建缓存即可，避免无效更新；若先删除缓存再更新数据库，数据库更新还未完成，此时其他线程查询到旧数据并重建缓存，此时就导致了数据长期不一致.

先更新数据库再删除缓存，更新数据库过程中，其他线程读取到了缓存未来的及删除的旧数据，但当数据库更新完毕后会删除缓存，后续请求会读到最新的数据并重建和缓存，只会导致中途短暂数据不一致，最终数据是一致的.

先更新数据库再删除缓存可能出现的极小概率极端情况:线程A进行数据更新的流程，线程A首先将进行数据库数据更新的操作，与此同时线程B查询缓存(此时缓存还没有被线程A删除)，但由于某中原因缓存提前失效，线程B查询到了数据库未来得及更新的旧数据并进行重建缓存的操作，但恰好在此期间线程A更新数据库完毕并删除了缓存，线程B在线程A删除了缓存后才进行缓存重建的操作，此时多种小概率事件叠加在一起导致了数据的长期不一致，此种情况发生概率较低.可以为缓存添加有效时间，一段时间后缓存失效，自动纠错.

存在的隐患: 更新数据库与删除缓存是两个操作,若删除缓存失败,缓存中还是旧值与数据库中的数据短期不一致，等自动过期后才会最终一致.

读策略: 如果读取的数据命中了缓存，则直接返回数据 ； 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。

若写操作较多旁路缓存方案会影响缓存命中率

若对缓存命中率要求较高，可采用【更新数据库+更新缓存】的方案，同时在此基础上增加别的手段避免并发问题:

分布式锁: 在更新缓存前加互斥锁,保证统一时间只有一个请求更新缓存，解决了并发问题;缺点:影响更新缓存的性能

较短过期时间: 给缓存加上较短过期时间,即便并发问题导致数据不一致,很快也会自动纠错，性能较好;缺点: 还是会出现短期数据不一致

旁路缓存优化,解决缓存删除失败的问题

旁路缓存优化 保证缓存删除成功

消息队列: 将删除缓存要操作的数据添加到消息队列中，由消费者操作数据；若删除缓存成功则移除数据，若删除缓存失败,则利用MQ提供的重试机制进行重试.缺点:入侵原业务,需要改造原有业务代码

订阅binlog+消息队列: 数据库更新成功后会生成相应的日志记录在binlog中，利用Canal订阅binlog，再将Canal订阅到的数据发送到MQ中，利用MQ将消息发送到消费者尝试删除即可. 不入侵原有业务代码,缺点: 引入的额外组件较多

延迟双删？

不实用，无法落地，无法确定第二次删除时机。

Redis 由浅入深 (5) - Redis 旁路方案 - 从RedisSession热切换到StandardSession
yh4494的博客
06-08 1174
Redis的旁路设计是指Redis在宕机之后或者网络不通的情况下，应用系统能够正常的访问，做出正确的缓存方案切换，一般指切换到应用缓存。不会造成系统不可访问的情况。但从redis集群的设计运维来说，redis肯定要保持高可用的，换句话说是在redis服务层面去做高可用，而不是应用层面去找替代方案。比如：redis挂了之后 80% ~ 90%是因为高并发或者是大对象缓存导致阻塞、连接满了，或者是主从复制内存耗尽。假如说这种情况出现，就算应用配置不错也是顶不住的。所以说一般情况下使用Redis集群是不需要做..
Flink优化之--旁路缓存和异步IO
datacreating的博客
08-29 1280
在异步模式下，单个并行子任务可以连续发送多个请求，按照返回的先后顺序对请求进行处理，发送请求后不需要阻塞式等待，省去了大量的等待时间，大幅提高了流处理效率。默认情况下，在Flink 算子中，单个并行子任务只能以同步方式与外部系统交互：将请求发送到外部存储，IO阻塞，等待请求返回，然后继续发送下一个请求。这就是flink的简单优化，综合来看，旁路缓存和异步IO的引入不仅解决了传统计算中存在的瓶颈问题，还为系统的可扩展性和稳定性提供了坚实的保障。堆缓存，性能更好，效率更高，因为数据访问路径更短。
Redis之旁路缓存
zzf1233的博客
05-14 2635
Redis之旁路缓存Redis作为缓存中间件早已深入人心，但我们有没有想过Redis为什么能作为缓存呢？Redis到底怎样使用缓存呢？本篇文章详细聊聊。Redis为什么能作为缓存聊Redis为什么能作为缓存前先需要清楚缓存的作用，我们在很多场景都有接触过缓存就如Redis本身的输入输出缓存、复制缓冲区、复制积压缓存区等等，又如操作系统本身的LLC，page cache缓存等等，这些缓存的主要作用是什么呢？是在一个多层次系统中平衡上下级系统的速度差异。这里以操作系统为例说明，操作系统的存储结构一般为CPU、内
采用Redis做旁路缓存，出现数据不一致的几种情况及处理方法
weixin_53803675的博客
05-11 934
针对旁路缓存出现不一致的问题，主要有以下几种情况： 1、更新数据库，然后更新缓存 这种情况在并发时，由于网络的问题，可能导致后来更新的数据早于先前更新的数据 线程1更新数据库 → 线程2更新数据库→ 线程2更新缓存→ 线程1更新缓存 此时出现后来更新的数据早于先前更新的数据，导致数据不一致问题 2、更新缓存，然后更新数据库 若先更新缓存，缓存更新成功后，但更新数据库时发生异常回滚，缓存中的数据无法回滚，导致数据不一致 3、删除缓存，然后更新数据库 线程1更新数据库，先删除缓存 → 线程1向数据库中写入数据
缓存的设计
yaoxie1534的博客
11-30 1432
一个读请求和一个写请求的并发，当写请求进来，把缓存删了，更新数据库这步操作还没完成，读请求进来，发现没缓存，往数据库中读取，这个时候数据库的数据还是老的数据，读请求把老的数据写入了缓存，然后写请求才把数据更新到数据库，这就造成了数据库和缓存的双写一致性问题。比方一个读操作，一个写操作的并发，读操作没有了删除缓存的操作，直接命中拿的是缓存中的数据，写操作更新了数据库中的数据，并删除了缓存，读操作读的就是老的数据。就是在更新晚数据库之后，sleep一段时间，再次进行删除缓存的操作，能极大的保证双写一致性。
23 Redis 的旁路缓存
热门推荐
海陆云的博客
12-10 2万+
23 Redis 的旁路缓存前言一、缓存的特征二、Redis 缓存处理请求的两种情况三、Redis 作为旁路缓存的使用操作四、缓存的类型总结 前言 Redis 提供了高性能的数据存取功能，广泛应用在缓存场景中，既能有效地提升业务应用的响应速度，还可以避免把高并发大压力的请求发送到数据库层。但如果 Redis 做缓存时出现了问题，比如缓存失效，大量请求就会直接积压到数据库层，必然会给数据库带来巨大的压力，很可能会导致数据库宕机或是故障，那么业务应用就没有办法存取数据、响应用户请求了。 正因为 Redis
Redis：代码实战之旁路缓存
张豫湘的博客
04-09 1051
但是当一个系统引入缓存时，需要面临最大的问题就是，如何保证缓存和后端数据库的一致性问题，最常见的3个解决方案分别是Cache Aside、Read/Write Throught和Write Back缓存更新策略，也就是下面所描述的两张缓存类型。缺点：高并发下的同步直写可能会发生缓存和数据库不一致的情形，由于写入数据库后写入缓存操作存在竞态条件（更新覆盖，由于请求数据库可能先请求后返回），需要配合分布式锁。所有写请求现在缓存处理，等增改的数据被从缓存中淘汰时，将需要淘汰的数据写入后端数据库。
低版本SpringBoot Redis缓存旁路设计改造方案实践
过了这个村没这个老王的博客
08-03 725
低版本SpringBoot Redis缓存旁路设计改造方案实践 目录 文章目录低版本SpringBoot Redis缓存旁路设计改造方案实践1. 引言1.1 编写目的1.2 读者对象2. 业务背景3. 适用场景4. 解决方案4.1 引入Redisson替换Lettuce4.2 修改配置文件4.3 更优雅的配置方式 1. 引言 1.1 编写目的 ​ 在越来越多的系统建设中，旁路设计受到重视，但是在低版本SpringBoot，以及其默认引入的Lettuce Redis客户端中，并没有很好的处理旁路问题。本文则
Flink实时维表查询优化-旁路缓存
Rango_lhl的博客
05-02 2304
一、背景说明： 在目前实时数仓中，由于维表具有主键唯一性的特点，Hbase/Redis通常作为维表存放选择 Hbase：数据存于磁盘具有持久性但是查询效率慢。 Redis：数据存于内存查询效率高，但维表多数据量大时候占用资源多。 基于旁路缓存思想，对维表存储的优化的思路为：维表数据存储在Hbase，使用Redis作为缓存，但查询维表时有限查询Redis，如果没有该维表则去Hbase查询后并将维表数据放入Redis，并按一定时间保存，超过时间Redis自动清理（可使不常用维表无需常驻内存，缺点是首次查询较
【redis】缓存模式——穿透型缓存和旁路型缓存
wosixiaokeai的博客
07-03 630
定义：特点：适用场景： 穿透型缓存适用于读多写多的场景，数据一致性要求较高的应用。定义：特点：适用场景： 旁路型缓存适用于读多写少的场景，数据一致性要求不高的应用。在实际应用中，旁路型缓存常常结合同步写回和异步写回两种写回策略来平衡数据可靠性和性能。数据一致性：实现复杂度：适用场景：性能考虑：
Redis 7.x 系列【37】旁路缓存模式
记录知识、锤炼自我
08-07 2035
缓存技术（Cache）通过将热点数据临时存储在查询速度更快的位置，从而提高了系统的响应速度和性能。‌ 计算机硬件、软件都大量使用了缓存技术，例如 CPU 中三级缓存，作为 CPU 与内存之间临时数据交换区， CPU 会将热点、相同的重复执行指令等数据放入到高速缓存中， CPU 直接从缓存中获取指令、数据，从而提高了整机的响应速度。
Redis学习笔记23——旁路缓存：Redis是如何工作的？
qq_34132502的博客
07-09 360
计算机系统中，默认有两种缓存： CPU 里面的末级缓存，即 LLC，用来缓存内存中的数据，避免每次从内存中存取数据； 内存中的高速页缓存，即 page cache，用来缓存磁盘中的数据，避免每次从磁盘中存取数据。 跟内存相比，LLC 的访问速度更快，而跟磁盘相比，内存的访问是更快的。所以，我们可以看出来缓存的第一个特征：在一个层次化的系统中，缓存一定是一个快速子系统，数据存在缓存中时，能避免每次从慢速子系统中存取数据。对应到互联网应用来说，Redis 就是快速子系统，而数据库就是慢速子系统了。 我们..
redis：作为旁路缓存的redis是怎么使用的
OceanStar的博客
10-10 812
缓存的特性 一个系统中的不同层之间的访问速度不一样，所以我们才需要缓存，这样就可以把一些需要频繁访问的数据放到缓存中，以加快它们的访问速度。 举个例子，计算机系统的存储结构一般是下面这样的： 所以，计算机系统中，默认有两种缓存： CPU里面的LLC缓存，用来缓存内存中的数据，避免每次从内存中存取数据 内存中的高速页缓存page cache，用来缓存磁盘中的数据，避免每次从磁盘中存取数据 从上面，我们可以看出缓存的第一条特性：在一个层次化的系统中，缓存一定是一个快速子系统，数据存在缓存中时，能避免每次
redis旁路缓存——击穿、雪崩、穿透
qq_42808312的博客
02-03 430
redis旁路缓存
Redis-旁路缓存策略详解
最新发布
weixin_44984196的博客
06-04 1358
Redisson 提供了多种机制来解决缓存一致性问题，具体选择哪种方案需要根据业务需求和系统特性来决定：如果需要强一致性，可以使用分布式锁。如果可以接受最终一致性，可以使用延迟双删、消息队列或 Binlog 异步更新。对于读写操作频繁的场景，可以使用读写锁。
23 _ 旁路缓存：Redis是如何工作的？
cjh的博客
01-10 239
我们知道，Redis提供了高性能的数据存取功能，所以广泛应用在缓存场景中，既能有效地提升业务应用的响应速度，还可以避免把高并发大压力的请求发送到数据库层。但是，如果Redis做缓存时出现了问题，比如说缓存失效，那么，大量请求就会直接积压到数据库层，必然会给数据库带来巨大的压力，很可能会导致数据库宕机或是故障，那么，业务应用就没有办法存取数据、响应用户请求了。这种生产事故，肯定不是我们希望看到的。正因为Redis用作缓存的普遍性以及它在业务应用中的重要作用，所以，我们需要系统地掌握缓存的一系列内容，包括工作原
Redis缓存篇之旁路缓存：Redis是如何工作的？
香农三定律的博客
12-10 785
Redis缓存篇之旁路缓存：Redis是如何工作的？缓存的特征Redis 缓存处理请求的两种情况Redis 作为旁路缓存的使用操作缓存的类型只读缓存读写缓存 缓存的特征 一个系统中的不同层之间的访问速度不一样，所以我们才需要缓存，这样就可以把一些需要频繁访问的数据放在缓存中，以加快它们的访问速度。 想象一下，如果每次 CPU 处理数据时，都要从 ms 级别的慢速磁盘中读取数据，然后再进行处理，那么，CPU 只能等磁盘的数据传输完成。这样一来，高速的 CPU 就被慢速的磁盘拖累了，整个计算机系统的运行速度会
redis-23 旁路缓存：Redis是如何工作的
weixin_38805083的博客
11-02 172
redis-23 旁路缓存：Redis是如何工作的
Redis缓存策略
weixin_42205001的博客
12-29 280
Redis缓存一般使用Cache Aside Pattern原则。 什么是“ Cache Aside Pattern ”？ Cache Aside Pattern即为旁路缓存方案的经验实践，分为读实践和写实践。 那么操作数据的时候先操作缓存还是先操作数据库? 1.读请求 先从缓存中读取所需数据，如果没有则从数据库里获取数据，后去之后需要进行新的缓存。 我一般在这里做一个AOP代理，把需要经常...
Redis 旁路缓存
05-10
<think>好的，用户现在想了解Redis旁路缓存的实现原理和优化方法。根据之前的对话，我已经给出了一些结构化的回答，但需要更深入地结合用户提供的引用内容来优化回答。 首先，我需要回顾用户提供的引用内容，确保准确引用。引用[1]提到旁路缓存需要应用程序处理缓存逻辑，Redis作为独立系统可以单独优化。引用[2]解释了缓存的作用是平衡速度差异，引用[3]强调Redis作为分布式缓存的优势，引用[4]讨论了Cache Aside模式在高写场景下的问题。 用户的问题集中在实现原理和优化方法，所以需要分两部分回答。实现原理部分要包括核心流程、读写操作细节，结合引用中的内容，比如应用程序的责任、缓存与数据库的交互。优化方法部分需要涵盖一致性、性能提升、异常处理，比如使用分布式锁（引用[1]提到的扩容优化）、布隆过滤器（引用[4]中的问题）、多级缓存（引用[3]中的场景）。 还要注意用户提到的“如何选择应用系统的缓存类型”，这可能暗示需要对比其他缓存模式，但用户现在只关注旁路缓存，所以重点应在优化策略。需要确保回答结构清晰，每个优化点都有对应的解决方案和引用支持，比如双删策略、TTL随机化、本地缓存结合等。 另外，用户可能关心实际应用中的问题，比如高并发下的缓存击穿，或者大量写入时的性能问题，需要结合引用[4]中提到的高写场景的弊端，给出相应的优化方法，比如异步更新、批量操作等。 最后，生成的相关问题需要基于现有内容，引导用户深入了解具体实现，如Redisson锁、布隆过滤器实现、多级缓存体系等，这些问题应自然衔接之前的回答，并引用对应的注释。</think>#### Redis旁路缓存的实现原理与优化方法 --- ### 一、核心实现原理 1. **基础架构设计** - **应用程序主导缓存逻辑**：所有缓存操作由业务代码显式控制（读时回填，写时失效），Redis仅作为独立存储层[^1] - **读写分离流程**： $$ \text{读操作流程} \rightarrow \begin{cases} \text{缓存命中} & \rightarrow \text{直接返回} \\ \text{缓存未命中} & \rightarrow \text{查询DB} \rightarrow \text{回填缓存（含TTL）} \end{cases} $$ $$ \text{写操作流程} \rightarrow \text{更新DB} \rightarrow \text{删除缓存} $$ 2. **核心特性** - **数据最终一致性**：通过删除缓存而非直接更新，避免并发写导致脏数据[^4] - **零缓存侵入**：数据库无需感知缓存存在，架构解耦（引用[2]中的速度差异平衡机制） 3. **关键技术支撑** ```java // Redis连接池配置示例 JedisPoolConfig config = new JedisPoolConfig(); config.setMaxTotal(100); // 控制最大连接数 config.setMaxIdle(30); // 防止连接泄露 JedisPool pool = new JedisPool(config, "redis-node1", 6379); ``` --- ### 二、关键优化方法 #### 1. 一致性优化 | 场景 | 解决方案 | 数学表达 | |------|----------|----------| | **并发写竞争** | 分布式锁+双删策略 | $Lock_{acquire}() \rightarrow Delete_{cache}() \rightarrow Update_{DB}() \rightarrow Delete_{cache}() \rightarrow Lock_{release}()$ | | **延迟双删** | 异步二次删除 | $t_{delay} = \Delta t_{主从同步} + \epsilon$ | | **缓存过期** | 动态TTL策略 | $TTL_{dynamic} = TTL_{base} \times (1 + \text{rand}(0,0.2))$ | **示例代码优化**： ```python def write_optimized(key, value): with redis.lock(f"lock:{key}", timeout=2): # 第一次删除 redis.delete(key) # 更新数据库 db.update(key, value) # 延迟二次删除（通过消息队列） mq.send_delayed_task(delete_cache_task(key), delay=500ms) ``` #### 2. 性能优化 - **批量管道化操作** 减少网络往返次数： ```redis > MULTI > GET user:1001 > GET product:2003 > EXEC ``` - **热点数据预加载** 结合LFU算法动态识别热点数据： $$ P_{预加载} = \frac{AccessCount_{key}}{TotalAccess} \times 100\% \quad (\text{当} P > 20\% \text{时触发}) $$ - **连接池优化** 根据QPS动态调整参数： $$ MaxConnections = \frac{QPS_{peak} \times AvgLatency}{1000} \times 1.2 $$ #### 3. 异常场景处理 - **缓存穿透** 布隆过滤器+空值缓存： ```java public Data getData(String key) { if (!bloomFilter.mightContain(key)) return null; // 布隆过滤 Data data = redis.get(key); if (data == null) { data = db.query(key); redis.setex(key, data != null ? data : NULL_VALUE, 60); // 空值缓存 } return data != NULL_VALUE ? data : null; } ``` - **缓存雪崩** 分层过期策略： ``` TTL分布： 30% keys → 5分钟±随机300秒 40% keys → 10分钟±随机600秒 30% keys → 15分钟±随机900秒 ``` --- ### 三、高级实践方案 1. **多级缓存架构** ```mermaid graph LR A[客户端] --> B[本地缓存] --> C[Redis集群] --> D[数据库] ``` - 本地缓存使用Caffeine，设置短TTL（如30秒） - 分布式缓存设置长TTL（如30分钟） 2. **异步更新队列** 针对高并发写场景（引用[4]的问题）： ```python # 写操作异步化示例 def async_update(key, value): mq.publish("db_update_queue", {"key": key, "value": value}) mq.publish("cache_invalidate_queue", {"key": key}) # 消费者处理 def db_update_consumer(): while True: message = mq.consume("db_update_queue") db.update(message.key, message.value) def cache_invalidate_consumer(): while True: message = mq.consume("cache_invalidate_queue") redis.delete(message.key) ``` 3. **监控指标优化** | 监控维度 | 关键指标 | 优化阈值 | |---------|----------|----------| | 缓存命中率 | Hit Rate = $\frac{CacheHits}{TotalRequests}$ | <90%触发告警 | | 连接利用率 | Utilization = $\frac{ActiveConnections}{MaxConnections}$ | >80%触发扩容 | | 延迟分布 | P99 Latency | >100ms触发优化 | --- ### 四、与Redis特性的深度结合 1. **Lua脚本原子化** 解决缓存与数据库状态不一致： ```lua -- 原子化查询+回填脚本 local data = redis.call('GET', KEYS[1]) if not data then data = db.query(KEYS[1]) -- 伪代码示意 redis.call('SETEX', KEYS[1], ARGV[1], data) end return data ``` 2. **内存淘汰策略调优** - 写密集型场景 → `volatile-lru` - 读密集型场景 → `allkeys-lfu` - 混合负载场景 → `volatile-ttl` + 主动预热 3. **持久化策略配置** ```conf # 根据数据重要性选择 save 900 1 # 15分钟1次修改触发RDB appendonly yes # 开启AOF appendfsync everysec # 折衷持久化性能 ``` ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值