7.Redis缓存面试题

什么是缓存？

缓存技术在现代计算机系统中扮演着至关重要的角色。它的核心价值在于通过空间换时间的方式，显著提升系统的性能。在计算机体系结构中，缓存存在于多个层次，从 CPU 缓存到内存缓存，再到磁盘缓存，每一层都发挥着不可替代的作用。

在应用层面，缓存的使用更加灵活多样。我们可以根据业务特点，选择合适的数据进行缓存。比如，对于频繁访问但很少修改的数据，缓存可以带来显著的性能提升；而对于实时性要求高的数据，则需要谨慎使用缓存，或者采用合适的缓存更新策略。

缓存有哪些价值

在现代互联网应用中，缓存已经成为不可或缺的技术组件。它的重要性主要体现在三个方面：性能提升、负载减轻和成本优化。

在性能方面，缓存通过减少对慢速存储的访问，显著提升了系统的响应速度。对于数据库查询、文件读取等耗时操作，缓存可以将响应时间从毫秒级降低到微秒级。这种性能提升在高并发场景下尤为重要，能够有效提升用户体验。

在系统负载方面，缓存起到了重要的分流作用。通过缓存热点数据，可以大幅减少对后端系统的请求压力。这不仅提高了系统的整体吞吐量，还降低了后端系统的资源消耗，使得系统能够支持更大的并发量。

在成本方面，缓存的使用可以带来显著的经济效益。通过减少对数据库等昂贵资源的访问，可以降低硬件投入和运维成本。同时，缓存的使用还可以减少网络带宽的消耗，进一步降低运营成本。

Redis缓存是如何应用的？

在缓存架构中，旁路缓存是最常见也是最实用的模式。这种模式的核心思想是将缓存作为数据库的补充，而不是替代。当需要读取数据时，首先尝试从缓存中获取，如果缓存未命中，再从数据库中读取并更新缓存。

举个例子，假设我们是一个订单系统，用户频繁来查订单，我们采用"先查Redis，未命中再查MySQL"的策略。当Redis中不存在所需数据时，我们会从MySQL中查询并将结果加载到Redis中，以便后续快速访问。

旁路缓存的优势在于实现简单、维护方便。它不需要复杂的缓存同步机制，只需要在适当的时机更新或删除缓存即可。这种模式特别适合读多写少的场景，能够显著提升系统性能。

Redis和MySQL的组合使用，本质上是一种"高速存储+低速存储"的架构模式。MySQL负责数据的持久化存储和复杂查询，Redis负责热点数据的快速访问。这种分工使得两个系统都能发挥各自的优势。

在性能方面，Redis的内存操作特性使其能够提供极高的读写性能。对于热点数据，Redis的访问延迟可以控制在微秒级别，这比MySQL的毫秒级延迟要快得多。这种性能差异在高并发场景下尤为明显。

在架构方面，Redis和MySQL的互补性使得系统既保证了数据可靠性，又获得了高性能。MySQL提供了强大的数据管理能力，而Redis则提供了快速的数据访问能力。这种组合特别适合互联网应用的需求。

Redis和Memcached有哪些共同点和不同点？

Redis和Memcached都是流行的开源内存数据存储系统，主要用于缓存场景以提高应用性能，但它们在设计理念、功能特性和适用场景上存在显著差异。

共同点

Redis和Memcached的核心目标都是通过内存存储数据来加速访问，减少对传统数据库（如MySQL、PostgreSQL）的依赖。它们都采用键值（Key-Value）存储模型，支持高速读写，适用于缓存会话数据、热点数据、临时数据等场景。两者都支持分布式部署，可以通过集群或分片的方式扩展存储容量和吞吐量。此外，它们都提供简单的协议（如Memcached的文本协议和Redis的RESP协议），便于客户端集成。

不同点

尽管有相似之处，但Redis和Memcached在数据持久化、数据结构、性能、扩展性等方面存在关键区别。

1. 数据结构支持
   Memcached仅支持简单的字符串（String）类型，适用于存储原始键值数据。而Redis提供了丰富的数据结构，包括字符串（String）、列表（List）、集合（Set）、有序集合（Sorted Set）、哈希（Hash）、位图（Bitmap）、HyperLogLog等。这使得Redis不仅能做缓存，还能实现更复杂的功能，如排行榜、消息队列、社交网络关系存储等。

2. 持久化与数据可靠性
   Memcached是纯内存缓存，重启后数据会丢失，适用于临时缓存场景。而Redis支持持久化，可以通过RDB（快照）和AOF（日志追加）两种方式将数据写入磁盘，确保数据在服务器崩溃后仍可恢复。这使得Redis可以用于需要数据持久化的场景，如会话存储、计数系统等。

3. 性能对比
   在纯缓存场景下，Memcached由于设计简单，通常在小数据量（如1KB以下）的读写性能略优于Redis。但Redis采用单线程模型（6.0+版本支持多线程I/O），在复杂操作（如范围查询、事务）上表现更优，并且在大数据量（如10KB以上）时性能更稳定。

4. 内存管理与扩展性
   Memcached采用多线程架构，能够更好地利用多核CPU，适合高并发读取。它使用Slab Allocation内存管理机制，减少内存碎片，但无法自动回收过期内存，可能导致内存浪费。Redis虽然是单线程处理命令，但通过高效的事件驱动模型和内存优化（如ziplist、quicklist）减少开销。此外，Redis支持内存淘汰策略（如LRU、LFU），可以自动清理不活跃数据，更灵活地管理内存。

5. 集群与高可用
   Memcached本身不支持主从复制或集群模式，需要依赖客户端分片（如一致性哈希）实现分布式存储。Redis则原生支持主从复制（Replication）、哨兵（Sentinel）和集群模式（Cluster），提供自动故障转移和数据分片，更适合大规模生产环境。

6. 适用场景
   Memcached适合简单的键值缓存，如HTML片段缓存、数据库查询结果缓存，尤其在高并发读取且数据可丢失的场景下表现优异。Redis则更适合需要持久化、复杂数据结构或高级功能的场景，如实时排行榜（Sorted Set）、消息队列（List/Stream）、分布式锁（SETNX）、社交网络（Set/Hash）等。

Redis做旁路缓存，如果MySQL更新了，此时何去何从？

这里是基于旁路缓存下，数据库一致性问题的考虑，首先我们要决策的，就是先更新数据库还是先更新缓存。

谁先更新

在Redis作为旁路缓存的架构中，通常选择先更新数据库，再删除/更新缓存，先更新数据库再处理缓存的核心优势在于它始终将数据库作为唯一真实数据源（Single Source of Truth）。

这种设计哲学确保了即使在最坏情况下（如缓存操作完全失败），系统仍能通过重新读取数据库恢复到一致状态。从ACID特性来看，数据库事务提供了原子性和持久性保证，而缓存本质上只是提高性能的临时存储，不应承担数据持久化的责任。

我们可以举个例子来说明：

• 错误顺序（先更新缓存）：1.更新Redis中的用户余额为200元（成功）；2.更新MySQL中的用户余额（失败）；3.结果：缓存显示200元，数据库仍是旧值100元，产生永久性不一致

• 正确顺序（先更新数据库）：1.新MySQL中的用户余额为200元（成功）；删除Redis中的用户余额缓存（失败）；3.下次读取时会从数据库重新加载，最终达到一致

这个案例清晰展示了先更新数据库如何提供更好的故障恢复能力。即使步骤2失败，系统仍能自我修复。下面我们的讨论，都是基于先更新数据库，再删除/更新缓存，这种大方向下，其实有三种处理思路。

思路一：过期时间兜底

为所有缓存数据设置合理的过期时间是保证最终一致性的基础手段。即使主动删除缓存失败，数据也会在过期后自动重新加载。这种机制实现简单，但存在一个主要问题：在过期时间内可能服务旧数据。

过期时间需要根据业务设置一个合理的值，时间太短容易造成缓存频繁失效，太长容易有较长时间不一致。

思路二：主动更新/删除

我们先说一下，一般来说，都是更新数据库后删除缓存，而不是更新缓存，这是因为删除之后加载，加载时数据一定是当前最新的。而更新则可能出现时序问题。

思路三：异步更新

通过订阅MySQL的binlog变更事件，利用消息队列异步更新缓存是理论上最彻底的解决方案。这种方案能实现准实时同步，对业务代码侵入性小，且能统一处理各种数据变更场景。但它的缺点同样明显：系统复杂度大幅增加，需要维护消息队列和消费者服务；存在一定延迟；需要处理消息积压和重复消费等问题。这种方案更适合数据一致性要求极高且团队具备相应运维能力的场景。

这种思路常用的落地方案是Canal，Canal作为阿里巴巴开源的MySQL binlog增量订阅组件，为缓存与数据库的一致性同步提供了企业级解决方案。下面我将从架构设计到具体实现，全面剖析这一方案的优劣及实施细节。

大概的工作原理如下：

1. Canal模拟MySQL slave的交互协议，伪装自己为MySQL从库：

2. 向Master发送dump协议获取binlog

3. 解析原始binlog事件（原始字节流）

4. 将解析结果结构化存储/转发，一般这一步就可以数据存储到缓存了

如何保证删除缓存操作一定能成功？

在数据库更新后立即删除对应缓存是最直接有效的方案。这种同步删除方式能最大程度减少不一致窗口，实现简单且效果显著。

但需要注意几个关键点：删除操作必须放在数据库事务提交之后，避免脏读；要考虑删除失败的重试机制；在高并发场景下可能产生竞态条件（如删除后立即被旧数据重新填充）。

针对这些问题，可以通过一些手段来优化：

• 延迟双删：先删除缓存，然后更新数据库，等待一段时间再删除缓存。保证第一个操作再睡眠之后，第二个操作完成更新缓存操作。但是具体睡眠多久其实是个玄学，很难评估出来，这个方案也只是尽可能保证一致性而已，依然也会出现缓存不一致的现象。

• 三次重试：三次同步重试，在后端领域也是常见的处理方式，能解决瞬时波动，当然重试之间可以有1、2s间隔

• 异步重试：将删除操作仍入消息队列，利用消息队列的消费重试能力，最终能完成删除操作，但是为了删除就引入这么重的组件或者说逻辑，成本有点过高了。

如何避免缓存失效？

缓存失效是缓存系统中不可避免的问题。当缓存数据过期时，系统需要重新从数据源加载数据，这个过程可能导致性能下降。我们需要采取适当的策略来减少缓存失效带来的影响。

后台检测机制可以提前发现并处理即将失效的缓存。通过定期检查缓存的有效性，我们可以在缓存失效前就更新数据，避免用户请求时才发现缓存失效。这种机制特别适合对性能要求高的场景。

缓存预热则是一种主动的缓存构建策略。在系统启动或业务高峰期前，我们预先将热点数据加载到缓存中，确保用户访问时能够直接从缓存获取数据。这种策略可以显著提升系统的初始响应速度。

什么是缓存穿透？如何解决？

缓存穿透是一个常见的缓存问题，它的本质是缓存失效导致的大量无效请求直接打到数据库。这种情况在恶意攻击或者系统设计不合理时经常发生，会对数据库造成巨大的压力。

解决缓存穿透的关键在于防止无效请求直接访问数据库。布隆过滤器是一个很好的解决方案，它可以在很小的内存空间内，快速判断一个元素是否存在于集合中。虽然布隆过滤器可能存在误判，但误判率可以通过参数调整控制在可接受范围内。

缓存空值也是一个有效的解决方案。当查询到数据库不存在的数据时，我们可以在缓存中存储一个空值，并设置一个较短的过期时间。这样，在短时间内再次查询相同的数据时，就可以直接从缓存中返回空值，避免重复查询数据库。

参数校验是预防缓存穿透的第一道防线。通过严格的参数校验，我们可以在请求到达缓存层之前就过滤掉明显无效的请求。这不仅可以防止缓存穿透，还能提高系统的安全性。

布隆过滤器是怎么工作的？

布隆过滤器是一种空间效率高的概率型数据结构，由位图数组和多个哈希函数组成。它的核心思想是：通过多个哈希函数将数据映射到位图数组的不同位置，通过检查这些位置的值来判断数据是否存在。布隆过滤器可以快速判断一个元素是否在集合中，但可能存在误判（假阳性），但不会漏判（假阴性）。

布隆过滤器的工作原理可以分为三个关键步骤：

第一步是哈希计算。当需要将数据写入布隆过滤器时，我们使用N个不同的哈希函数对数据进行哈希计算，得到N个哈希值。这些哈希函数需要是相互独立的，以确保映射的均匀性。

第二步是位置映射。将第一步得到的N个哈希值对位图数组的长度取模，得到每个哈希值在位图数组中的对应位置。这个步骤确保了哈希值能够均匀地分布在整个位图数组中。

第三步是标记设置。将位图数组中对应位置的值设置为1，表示该位置被占用。当所有N个位置都被标记后，数据的写入就完成了。

在查询时，我们只需要检查数据对应的N个位置是否都为1。如果所有位置都为1，说明数据可能存在（可能存在误判）；如果有任何一个位置为0，说明数据一定不存在（不会漏判）。

布隆过滤器有什么缺陷？

布隆过滤器虽然高效，但也存在一些重要的缺陷，主要体现在以下几个方面：

误判问题是布隆过滤器最核心的缺陷。由于哈希冲突的存在，不同的数据可能会映射到位图数组的相同位置。这就导致了一个数据被判断为"存在"时，实际上可能并不存在。这种误判是不可避免的，但可以通过增加位图大小和哈希函数数量来降低误判率。

不支持删除操作是另一个重要缺陷。由于多个数据可能共享同一个位置，直接删除一个数据的标记可能会影响到其他数据。虽然可以通过使用计数布隆过滤器（Counting Bloom Filter）来支持删除，但这会显著增加内存消耗。

无法获取原始数据是布隆过滤器的本质限制。布隆过滤器只存储了数据的存在性信息，而不存储数据本身。这意味着它只能用于判断数据是否存在，而不能用于存储或获取数据。

什么是缓存击穿？如何解决？

缓存击穿是分布式系统中常见的高并发场景下的典型问题，其核心特征表现为当某个热点数据的缓存失效时，瞬间有大量并发请求直接穿透缓存层，同时访问底层数据库系统。这种现象会对数据库造成巨大的瞬时压力，严重时可能导致数据库连接池耗尽、响应延迟增加，甚至引发级联故障，进而影响整个系统的稳定性和可用性。

要深入理解缓存击穿问题，需要明确其发生的三个必要条件：首先，必须是访问频率极高的热点数据；其次，该数据的缓存恰好处于失效状态；最后，在这个失效时间点有大量并发请求同时到达。与缓存穿透和缓存雪崩不同，缓存击穿针对的是特定热点数据的失效场景，这使得它的解决方案需要更加精准和高效。

解决缓存击穿问题的核心设计原则是通过各种技术手段来避免大量请求在同一时刻直接访问数据库。目前业界主要有以下几种成熟的解决方案，每种方案都有其适用场景和实现细节：

互斥锁方案是最经典和广泛应用的解决方案。其实现原理是当缓存失效时，不是所有请求都立即访问数据库，而是通过分布式锁机制确保只有一个请求线程能够获得数据加载的权限。具体实现时，第一个发现缓存失效的请求会尝试获取一个互斥锁，成功获取锁的线程负责查询数据库并重建缓存，而其他并发请求则会被阻塞等待或者直接返回预定义的默认值。这种方案的关键在于锁的粒度控制、锁的超时处理以及等待请求的降级策略。在实际工程实现中，可以使用Redis的SETNX命令实现分布式锁，同时需要设置合理的锁超时时间，防止因异常情况导致死锁。此外，对于等待的请求，可以采用快速失败或异步通知等不同策略来平衡系统吞吐量和用户体验。

热点数据永不过期方案适用于那些变更频率不高但访问极其频繁的关键数据。这种方案通过取消缓存的有效期限制，从根本上避免了因缓存失效导致的击穿问题。具体实现时，系统会为这些特殊的热点数据设置一个理论上的长期有效期（如10年），同时通过后台定时任务或消息触发机制来异步更新缓存数据。这种方案的优点是完全消除了缓存失效时间窗口，但需要配套完善的数据更新机制。在实践中，通常会结合发布订阅模式或数据库binlog监听等技术来实现缓存的及时更新，确保数据的最终一致性。需要注意的是，这种方案会占用更多的内存资源，因此只适用于真正的高价值热点数据。

提前更新缓存方案是一种主动预防型的解决方案。该方案通过在缓存即将过期前就启动异步刷新流程，确保在旧缓存失效时新缓存已经准备就绪。具体实现时，可以设置两个过期时间：一个是逻辑过期时间，用于判断数据是否陈旧；一个是实际过期时间，比逻辑过期时间稍长。当检测到数据接近逻辑过期时间时，系统会异步触发缓存更新任务。这种方案的优点是对用户体验影响最小，但实现复杂度较高，需要精心设计缓存标记和更新触发机制。在实际应用中，可以结合定时任务和访问频率监控来实现智能的预刷新策略，对于不同热度的数据采用不同的刷新提前量。

除了上述主流方案外，分级缓存和多级过期策略也是应对缓存击穿的有效手段。分级缓存通过在应用层和分布式缓存层之间增加本地缓存，利用多级缓存结构来分散压力；多级过期策略则是对同一个数据设置多个具有随机偏移量的过期时间，避免所有缓存同时失效。这些方案往往需要根据具体业务场景进行组合使用。

在选择具体解决方案时，需要综合考虑业务特征、数据一致性要求、系统复杂度等因素。对于金融交易等强一致性要求的场景，可能需要以性能为代价优先保证数据准确性；而对于内容展示等高并发场景，则可以适当放宽一致性要求来换取更高的系统吞吐量。无论采用哪种方案，完善的监控和熔断机制都是必不可少的，需要实时监控缓存命中率、数据库负载等关键指标，以便及时发现和处理潜在问题。

什么是缓存雪崩？如何解决？

缓存雪崩是指在高并发场景下，大量缓存数据同时失效或缓存服务宕机，导致所有请求直接穿透到数据库，造成数据库瞬时压力激增，甚至引发系统崩溃的现象。与缓存击穿（针对单个热点数据失效）不同，缓存雪崩的影响范围更广，通常是多个缓存键同时失效或整个缓存集群不可用，因此对系统的破坏性更强。

缓存雪崩的成因

缓存数据同时过期：如果大量缓存设置了相同的过期时间（例如，系统初始化时批量加载数据并设置相同的TTL），那么它们可能会在同一时间失效，导致所有相关查询同时访问数据库。

缓存服务宕机：如果Redis等缓存服务因网络问题、硬件故障或高负载而不可用，所有请求都会直接落到数据库上。

热点数据突发访问：某些突发事件（如秒杀活动、热点新闻）可能导致大量请求涌入，如果缓存未能及时预热或更新，数据库可能因无法承受高并发而崩溃。

缓存雪崩的解决方案

1. 缓存过期时间随机化

避免大量缓存同时失效的最直接方法是对缓存过期时间进行随机化。例如，可以在基础TTL的基础上增加一个随机偏移量（如 TTL + random(0, 300s)），这样即使数据同时加载，它们的过期时间也会分散在不同的时间点，避免集中失效。

2. 缓存预热与后台刷新

• 缓存预热：在系统启动或低峰期，提前加载热点数据到缓存，避免冷启动时大量请求直接访问数据库。

• 后台定时刷新：对于关键数据，可以采用“逻辑过期”策略，即缓存数据本身不设置过期时间，而是通过异步任务或定时任务定期更新，确保缓存始终可用。

3. 多级缓存架构

采用多级缓存（如 本地缓存 + 分布式缓存）可以降低对单一缓存层的依赖，比如本地缓存（如Caffeine、Guava Cache）：作为第一层缓存，减少对Redis的访问压力；分布式缓存（如Redis）：作为第二层缓存，提供全局一致性。如果Redis宕机，本地缓存仍能支撑部分流量，避免数据库被瞬间击垮。

4. 熔断降级与限流机制

• 熔断降级：当检测到缓存层异常或数据库压力过大时，系统可以自动降级，返回默认数据或错误页面，避免雪崩扩散。

• 限流：通过限流算法限制数据库的访问速率，也可以通过分布式锁进行访问限制，确保系统在极端情况下仍能保持基本可用性。

5. 高可用缓存集群

• Redis Cluster / Sentinel：部署高可用的Redis集群，避免单点故障。

• 异地多活：对于核心业务，可以采用多机房部署，即使某个机房的缓存服务宕机，其他机房仍能提供服务。

如何评估缓存的效果？

评估缓存效果是一个系统性的工作，需要从多个维度进行综合评估。缓存命中率是最直观的指标，它反映了缓存的使用效率。一个设计良好的缓存系统，命中率通常应该达到80%以上。但是，仅仅关注命中率是不够的，我们还需要考虑命中率背后的成本。

响应时间是评估缓存效果的重要指标。通过对比使用缓存前后的响应时间，我们可以直观地感受到缓存带来的性能提升。需要注意的是，响应时间的评估应该考虑不同场景下的表现，比如正常负载、高负载、缓存失效等场景。

系统吞吐量是评估缓存效果的综合指标。缓存的使用应该能够提升系统的整体吞吐量，使得系统能够处理更多的并发请求。同时，我们还需要关注系统资源的利用情况，确保缓存的使用不会带来过大的资源消耗。

成本效益分析是评估缓存效果的重要方面。我们需要考虑缓存带来的性能提升与资源消耗之间的平衡。这包括内存使用、CPU消耗、网络带宽等资源的使用情况。通过成本效益分析，我们可以判断缓存的使用是否合理，是否需要进行优化。

如何优化缓存性能？

缓存性能优化是一个持续的过程，需要从多个方面进行综合考虑。提高缓存命中率是最直接的优化方向，这包括合理设置缓存容量、选择合适的缓存策略、优化缓存更新机制等。通过提高命中率，我们可以减少对后端系统的访问，提升系统整体性能。

减少缓存失效是另一个重要的优化方向。我们可以通过设置合理的过期时间、实现缓存预热、使用缓存更新策略等方式，减少缓存失效带来的性能影响。特别是对于热点数据，我们可以采用更激进的缓存策略，确保数据始终可用。

优化缓存更新策略可以提升缓存效率。我们可以根据数据特点，选择合适的更新策略。对于实时性要求高的数据，可以采用同步更新策略；对于实时性要求不高的数据，可以采用异步更新策略。同时，我们还需要考虑更新失败的处理机制，确保系统的可靠性。

使用多级缓存架构可以进一步提升系统性能。通过在不同层次设置缓存，我们可以减少对后端系统的访问，提升系统响应速度。这种架构虽然实现复杂，但能够带来显著的性能提升。