Redis缓存管理机制

在当今快节奏的数字世界中，性能优化对于提供无缝的用户体验至关重要。缓存在提高应用程序性能方面发挥着至关重要的作用，它通过将经常使用或处理的数据存储在临时高速存储中来减少数据库负载并缩短响应时间，从而减少系统的延迟。Redis 是一种流行的内存数据存储，它提供了强大的缓存解决方案，可以显着提高应用程序的速度和效率。

在深入研究 Redis 缓存之前，让我们先了解缓存的基础知识。缓存涉及将经常访问或计算成本高昂的数据存储在快速且易于访问的位置（例如内存）中，以加快后续请求的速度。通过将数据存储在缓存中，应用程序可以避免从速度较慢的数据源（如数据库或外部 API）获取数据的需要，从而缩短响应时间并减少服务器负载。

Redis就像是一个超级快的小助手,站在数据库和应用程序之间（可以类比CPU，缓存，内存）: Redis把数据存在内存里,就像把常用的东西放在手边一样,取用起来超快。相比之下,数据库就像是要去仓库找东西,慢很多。

使用 Redis 缓存时，请务必考虑以下内容：

确定要缓存的正确数据：并非所有数据都需要缓存。专注于缓存经常访问或生成计算成本高昂的数据。这包括不经常更改或可以在多个请求之间共享的数据。

设置过期策略：为缓存的数据确定适当的过期策略。这可确保缓存保持最新状态，并避免提供过时的数据。根据数据更新的频率和缓存数据所需的新鲜度设置过期时间。

实现缓存失效：当基础数据发生变化时，必须使相应的缓存条目失效或更新。这可以通过使用缓存失效触发器或监视数据源中的更改等技术来完成。

监控缓存性能：定期监控缓存性能，确保其有效性。密切关注缓存命中率、缓存未命中率和整体缓存利用率。监控可以帮助识别潜在的瓶颈或需要优化的领域。

针对高流量扩展 Redis：随着应用程序流量的增长，请考虑扩展 Redis 以处理增加的负载。这可能涉及使用 Redis 集群或复制在多个实例之间分配数据并提高读取和写入吞吐量。

---

缓存策略

a) 读取数据时:

• 应用程序先问Redis:"嘿,你有这个数据吗?"

b) 写入数据时:

• 如果Redis说"有",应用程序就直接用了,省去了问数据库的时间。
• 如果Redis说"没有",应用程序就去数据库拿,然后告诉Redis:"保存一下,下次可能用得着。"
• 应用程序更新数据库,然后告诉Redis:"嘿,数据更新了,你也更新一下。"

Redis的缓存策略主要涉及如何有效地管理缓存数据，以及如何保持缓存与数据源的一致性。让我们通过几个主要的缓存策略来深入了解：

1. Cache-Aside（旁路缓存）

想象Redis是一个效率极高的助手，而数据库是一个大型档案室。

工作流程：

• 读取数据：应用先查Redis，没有则去数据库取，然后放入Redis。
• 写入数据：先更新数据库，再删除Redis中的对应键。

比喻：你想找一份文件。首先问助手（Redis）有没有，如果没有，你就去档案室（数据库）找，找到后给助手一份副本。当你需要更新文件时，先更新档案室的原件，然后告诉助手丢掉手中的旧副本。

优点：实现简单，Redis挂掉不影响系统正常运行。保证数据一致性。

缺点：第一次访问数据时会比较慢（称为"缓存穿透"）。

2. Read/Write Through（读写穿透）

想象Redis现在变成了一个聪明的管家，所有的数据请求都必须经过他。

工作流程：

• 读取数据：应用只和Redis交互，如果Redis没有数据，Redis负责从数据库读取并缓存。
• 写入数据：应用把数据写入Redis，Redis负责同步更新到数据库。

比喻：你需要任何文件都告诉管家（Redis）。如果管家没有，他会去档案室（数据库）取，然后保存一份。当你要更新文件时，你把新文件交给管家，由他负责更新档案室。

优点：对应用层透明，应用不需要关心缓存的细节。数据一致性好。

缺点：增加了Redis的复杂度。可能会带来一定的性能损失。

3. Write-Behind Caching（异步写入）

把Redis想象成一个能暂存数据的智能助理。

工作流程：

• 读取数据：与Read Through相同。
• 写入数据：数据写入Redis后立即返回，Redis异步地将数据更新到数据库。

比喻：你把所有更新的文件都交给助理（Redis）。助理先记录下来，然后在空闲时统一更新到档案室（数据库）。

优点：写操作性能高。可以合并多次写操作，减少数据库压力。

缺点：

数据丢失风险高，Redis宕机可能导致未同步的数据丢失。

数据一致性较弱，可能出现Redis和数据库数据不一致的情况。

4. 预加载策略

将Redis视为一个预习室。

工作流程：在系统启动或者定时任务中，主动将热点数据加载到Redis中。

比喻：在开始工作前，助理（Redis）主动去档案室（数据库）取出可能会用到的文件，放在手边以备不时之需。

优点：可以提前准备热点数据，提高访问速度。减少缓存穿透的情况。

缺点：需要提前预测热点数据，如果预测不准确可能会浪费资源。

5. 多级缓存策略

将Redis作为多级缓存系统中的一环。

工作流程：
构建本地缓存（如应用服务器的内存） -> Redis -> 数据库的多级缓存架构。

比喻：你的办公室有个小抽屉（本地缓存），办公室外有个文件柜（Redis），大楼里有个档案室（数据库）。你会先看抽屉，然后是文件柜，最后才去档案室。

优点：进一步提高数据访问速度。减轻Redis的压力。

缺点：增加了系统复杂度。多级缓存一致性维护变得更加困难。

选择哪种缓存策略取决于你的具体需求，如对数据一致性的要求、系统的读写比例、性能需求等。在实际应用中，常常会综合使用多种策略来达到最佳效果。

redis把登入的数据都登录在了缓存内存中，避免了浪费时间的IO操作，但是随着数据量的增加redis存储的数据也会越来越多，所以接下来引入了过期策略

---

过期策略

设置过期策略：为缓存的数据确定适当的过期策略。这可确保缓存保持最新状态，并避免提供过时的数据。根据数据更新的频率和缓存数据所需的新鲜度设置过期时间。

Redis不会永远保存所有数据,它会给数据设置"保质期"。

• 就像冰箱里的食物,过期了就自动扔掉。
• 这样可以保证Redis里always存着新鲜的数据。

Redis 主要使用三种策略来管理过期的键：定时删除、惰性删除和内存淘汰。让我们用简单的比喻来理解这些概念。

1. 定时删除（主动删除）

想象 Redis 是一个图书管理员，而键就是借出去的书。

• 工作原理：Redis 会为每个设置了过期时间的键都创建一个定时器，一旦到期，就立即删除。
• 比喻：图书管理员给每本借出去的书都设置了一个闹钟。闹钟一响，他就立即去找到这本书并将其下架。
• 优点：内存友好，过期键能被及时删除。
• 缺点：CPU 不友好，可能会占用大量 CPU 时间去处理过期键。

实际上，Redis 用的是一种折中的策略：每秒进行 10 次过期键的检查，每次随机检查一些设置了过期时间的键，删除其中已过期的。

2. 惰性删除（被动删除）

想象 Redis 现在变成了一个懒惰的图书管理员。

• 工作原理：Redis 不主动删除过期键，只有当你尝试访问一个键的时候，才会检查它是否过期，如果过期了就删除。
• 比喻：图书管理员不主动检查书的借阅期。只有当有人来借书时，他才会检查这本书是否已经过期，如果过期了就将其下架。
• 优点：CPU 友好，不会浪费 CPU 时间去检查未被使用的过期键。
• 缺点：内存不友好，过期的键可能会在很长一段时间内占用内存。

3. 内存淘汰（内存不足时的被动删除）

想象 Redis 是一个书架空间有限的图书馆管理员。

• 工作原理：当 Redis 的内存不足以容纳新的数据时，会根据选定的淘汰策略来删除一些键，为新数据腾出空间。
• 比喻：当书架快满时，图书管理员会根据某种规则（比如最少使用、最近最少使用等）来决定哪些书要被移除，以便放入新书。

Redis 提供了几种内存淘汰策略：

a) noeviction：不淘汰任何数据，当内存不足时直接报错。

比喻：书架满了就不再接受新书，并告诉借书人"对不起，没位置了"。

b) allkeys-lru：从所有键中驱逐使用频率最少的键。

比喻：移除最长时间没人看过的书。

c) volatile-lru：从设置了过期时间的键中驱逐使用频率最少的键。

比喻：只在有"借阅期限"的书中，移除最长时间没人看过的书。

d) allkeys-random：随机驱逐键。

比喻：随机选择书本移除。

e) volatile-random：从设置了过期时间的键中随机驱逐。

比喻：在有"借阅期限"的书中随机选择移除。

f) volatile-ttl：驱逐快要过期的键。

比喻：优先移除快到"借阅期限"的书。

g) volatile-lfu 和 allkeys-lfu（Redis 4.0 新增）：驱逐使用频率最低的键。

比喻：移除借阅次数最少的书。

实际应用中，Redis 会综合使用这些策略。定时删除和惰性删除是主要的过期键处理方式，而内存淘汰策略则是在内存紧张时的一种补充措施。选择合适的策略需要根据实际应用场景和需求来权衡。

---

缓存问题及它们的解决方案

1. 缓存击穿（Cache Penetration）

概念：
缓存击穿指的是对于一个特定的高频热点key，在缓存过期的一刻，同时有大量的请求到达，这些请求同时发现缓存过期，于是同时去数据库中查询数据，导致数据库瞬间压力剧增。

比喻：
想象一个热门商品在电商平台上的缓存刚好过期，而此时正值促销高峰，大量用户同时刷新页面，导致所有请求都直接冲向数据库。

解决方案：

a) 互斥锁（Mutex Key）
   - 原理：第一个请求获取锁并从数据库加载数据，其他请求等待。
   - 实现：使用Redis的SetNX命令，成功设置则获取锁。
   - 优点：简单有效，保证只有一个请求会穿透到数据库。
   - 缺点：可能会造成某些请求的等待时间较长。

b) 设置热点数据永不过期
   - 原理：对于某些特别热点的数据，设置一个较长的过期时间或干脃不设置过期时间。
   - 实现：定期异步更新这些热点数据。
   - 优点：能有效防止缓存击穿。
   - 缺点：维护成本较高，需要额外的更新机制。

c) 提前更新缓存
   - 原理：在缓存即将过期前，异步更新缓存。
   - 实现：设置一个缓存刷新线程，检测即将过期的key并提前更新。
   - 优点：能有效避免缓存过期瞬间的压力。
   - 缺点：实现相对复杂，需要额外的系统资源。

2. 缓存雪崩（Cache Avalanche）

概念：
缓存雪崩指的是大量缓存数据在同一时间集中过期，或者缓存服务器宕机，导致大量请求直接落到数据库上，引起数据库压力骤增，可能导致整个系统崩溃。

比喻：
想象一场大型促销活动结束，所有商品的缓存同时失效，或者Redis服务器突然宕机，导致所有的请求如雪崩般冲向数据库。

解决方案：

a) 均匀分布过期时间
   - 原理：在设置缓存过期时间时加入一个随机值，避免大量缓存同时过期。
   - 实现：过期时间 = 基础过期时间 + random(0, 300秒)
   - 优点：简单有效，易于实现。
   - 缺点：可能会稍微增加缓存不一致的概率。

b) 构建高可用的缓存集群
   - 原理：使用Redis Cluster或者哨兵模式，确保缓存系统的高可用性。
   - 实现：配置主从复制，并使用哨兵监控和自动故障转移。
   - 优点：大大提高系统的可用性和稳定性。
   - 缺点：增加了系统复杂度和维护成本。

c) 设置多级缓存
   - 原理：在Redis之上再增加一层本地缓存（如Guava Cache）。
   - 实现：请求首先访问本地缓存，miss后再访问Redis。
   - 优点：即使Redis完全不可用，系统仍能提供部分服务。
   - 缺点：增加了系统复杂度，且可能带来数据一致性问题。

d) 熔断降级机制
   - 原理：当检测到缓存服务不可用时，暂时屏蔽部分非核心功能，只提供最基本的服务。
   - 实现：使用类似Hystrix这样的熔断框架。
   - 优点：能够保护系统核心功能，防止整体崩溃。
   - 缺点：会暂时降低用户体验。

e) 预加载热点数据
   - 原理：系统启动时或者定时任务中提前加载热点数据到缓存。
   - 实现：编写脚本或定时任务，定期刷新热点数据的缓存。
   - 优点：可以有效减少缓存雪崩的影响范围。
   - 缺点：需要额外的维护成本，且可能会占用更多的缓存空间。

在实际应用中，通常会综合使用多种策略来防范缓存击穿和缓存雪崩。选择哪种方案或组合要根据具体的业务场景、系统架构和性能需求来决定。同时，良好的监控和告警机制也是必不可少的，可以帮助我们及时发现并解决问题。

3. 缓存失效（ Cache Invalidation）

1. 避免缓存失效

a) 定时刷新策略

• 原理：定期更新缓存中的数据，不依赖于单个数据变更。
• 优点：简单可靠，适合变更频率较低的数据。
• 缺点：可能存在短暂的数据不一致。

b) 基于消息队列的实时更新

• 原理：数据变更时发送消息，专门的服务消费消息并更新缓存。
• 优点：实时性高，系统解耦。
• 缺点：需要额外的消息中间件，增加系统复杂度。

c) 双写一致性（Write-Behind）

• 原理：更新数据时同时更新缓存和数据库，通过异步队列保证最终一致性。
• 优点：保证缓存和数据库的最终一致性。
• 缺点：实现复杂，需要处理各种异常情况。

2. 缓存监测方法

a) 健康检查

• 原理：定期检查缓存服务的可用性和响应时间。
• 作用：及时发现缓存服务的异常。

b) 缓存命中率监控

• 原理：统计缓存的命中次数和未命中次数，计算命中率。
• 作用：评估缓存效率，指导缓存策略优化。

c) 过期键监控

• 原理：监控即将过期或已过期的键数量。
• 作用：预防大规模缓存失效，避免缓存雪崩。

d) 内存使用监控

• 原理：监控Redis的内存使用情况。
• 作用：防止内存溢出，指导容量规划。

e) 慢查询日志分析

• 原理：分析Redis的慢查询日志，找出性能瓶颈。
• 作用：优化缓存查询性能，改进缓存策略。

参考

Redis Cache - GeeksforGeeks

【趣话Redis第一弹】我是Redis，MySQL大哥被我坑惨了！_哔哩哔哩_bilibili