当前位置：首页 > news >正文

【每日八股】复习 Redis Day3：Redis 的应用

news 来源：原创 2025/5/1 7:28:02

文章目录

昨日内容复习
- 简述 Redis 持久化的两种策略
- AOF 的三种持久化/写回策略？
- AOF 的磁盘重写机制？
- 为什么要先执行一个 Redis 命令，再将命令写入到 AOF 缓冲区？
- AOF 磁盘重写期间子进程的内存跟主进程内存的数据不一致怎么办？
- RDB 执行快照期间，数据可以修改吗？
- RDB 的过期机制？
- Redis 的内存淘汰策略？
- Redis 持久化对过期键如何处理？
- Redis 主从模式中对过期键如何处理？
复习 Redis Day3：Redis 的应用
- 缓存雪崩、缓存击穿、缓存穿透的现象解释及解决办法？
- 如何保证数据库和缓存的一致性？
- - 普通方案
  - 进阶方案
- 如何保证删除缓存一定成功？
- 针对业务一致性要求高的场景，如何确保缓存与数据库的一致性？
- 如何避免缓存失效？
- 如何实现延迟队列？
- 如何设计一个缓存策略，以动态缓存热点数据呢？
- Redis 实现分布式锁？
- 使用 Redis 实现分布式锁的优缺点？
- Redis 如何解决集群模式下分布式锁的可靠性？
- Redis 管道有什么用？管道与事务有什么区别？
- - Redis 管道（Pipeline）
  - Redis 事务（Transaction）
- Redis 事务与 MySQL 事务的区别？

昨日内容复习

首先对 Redis 持久化部分的知识进行完全的复习。

简述 Redis 持久化的两种策略

Redis 持久化的两种策略分别是 RDB 和 AOF。

RDB 会 fork() 一个子进程来记录 fork() 时刻 Redis 缓存的快照，生成的 RDB 文件体积较小，常用于容灾恢复，缺点在于如果 RDB 持久化之前 Redis 服务崩溃，会丢失这段时间的数据。

AOF 会在 Redis 命令之后将写命令追加到 AOF 缓冲区，并择期持久化到磁盘当中。AOF 文件体积较大，在通过 AOF 恢复时需要一条条执行 AOF 当中的语句，优点是安全性较好，在默认持久化策略下最多丢失「1 秒」的数据。

AOF 的三种持久化/写回策略？

always：每一条语句执行后直接持久化到磁盘当中，安全性最佳，但是以性能为代价；
everysec：Redis 语句执行后将语句先放入到 AOF 缓冲区当中，每秒将缓冲区当中的语句持久化到磁盘，最多丢失 1 s 数据；
no：由操作系统择机将 AOF 缓冲区当中的数据持久化到磁盘。

AOF 的磁盘重写机制？

当 Redis 写命令较多时，AOF 文件占用的存储空间会非常的大，并且当中可能存在无效或重复的命令，为了精简 AOF 文件，Redis 会 fork() 一个子进程，来执行 AOF 重写。

具体来说，AOF 重写会将 fork() 时刻的 Redis 缓存快照转换为 Redis 写命令，存储到新的 AOF 文件当中，在此期间新追加的 AOF 命令会同时写入到 AOF 缓冲区以及 AOF 重写缓冲区当中。当 AOF 重写完成后，重写缓冲区中的命令写入到新的 AOF 文件，并替换旧的 AOF 文件，完成 AOF 磁盘重写。

为什么要先执行一个 Redis 命令，再将命令写入到 AOF 缓冲区？

确保 Redis 写入 AOF 缓冲区当中的每一条指令都是正确的，这样在使用 AOF 恢复时，不必重新检查命令的合法性。

AOF 磁盘重写期间子进程的内存跟主进程内存的数据不一致怎么办？

AOF 磁盘重写时，主进程通过 fork() 生成一个子进程，该子进程与主进程在 fork() 时共享相同的内存页。AOF 重写开启后，主进程继续处理来自客户端的 Redis 请求，如果主进程的缓存发生修改，那么触发「写时复制」，主进程会在此时复制一个新的内存页并对此进行修改，而子进程看到的仍然是 fork() 时的内存页。

AOF 重写时，Redis 开启一个 AOF 重写缓冲区，新的客户端命令会同时写入 AOF 缓冲区与 AOF 重写缓冲区，AOF 重写完成后，重写缓冲区当中的命令追加到新的 AOF 文件当中，完成 AOF 重写。

RDB 执行快照期间，数据可以修改吗？

可以修改，与 AOF 重写期间追加写命令的逻辑相同。

RDB 在开启快照时，主进程 fork() 一个子进程并共享内存页，当客户端写入命令时，触发「写时复制」，主进程复制一个新的内存页并在其上进行修改，而子进程看到的仍然是之前的内存页。

RDB 的过期机制？

Redis 允许为 Key 设置「生存时间（TTL）」，到期后自动删除。通过「定期删除 + 惰性删除」的组合来实现。

惰性删除

当客户端尝试访问某个键时，如果这个键已经过期了，则直接删除并返回 nil，否则返回正常数据。
优点：CPU 友好，只处理实际访问的键；
缺点：有一些过期的键可能永远不会被访问到，导致内存开销变大；

定期删除

Redis 每隔一段时间会随机抽取一部分键检查是否过期，如果过期就删除。默认每次检查 20 个键，如果发现其中超过 25% 过期，那么继续抽取下一批，直到比例低于 25% 或超时。
优点：降低内存泄漏的风险。
缺点：可能无法完全删除所有键。

Redis 的内存淘汰策略？

Redis 的内存达到上限后，会根据指定的淘汰策略自动删除键，以释放内存空间。

不进行内存淘汰
内存超限后，仍然可以读，但是新的写命令到来时，将会返回 OOM 错误。

在设置了过期时间的数据中淘汰

volatile-random：随机淘汰设置了 TTL 的任意键值；
volatile-ttl：优先淘汰更早过期的键值；
volatile-lru：淘汰所有设置了 TTL 的键值当中最久未使用的键值；
volatile-lfu：淘汰所有设置了 TTL 的键值当中最少使用的键值；

在所有数据当中淘汰

allkeys-random：随机淘汰部分键值；
allkeys-lru：淘汰最久未使用键值；
allkeys-lfu：淘汰最少使用键值；

Redis 持久化对过期键如何处理？

RDB

生成 RDB 快照时，跳过过期的键值；
通过 RDB 快照恢复时，如果 Redis 以主节点模式启动，会检查过期键时间，并在加载后立即删除过期的键。如果以从节点模式启动，由于从节点不会主动删除键值，因此会加载包括过期键在内的所有键值，仅通过主节点 DEL 命令的同步来删除过期键。

AOF

AOF 文件记录：写入 AOF 的过期键以 DEL 命令行事记录；
AOF 重写：子进程生成新的 AOF 时自动跳过过期键，如果在重写期间过期，那么主进程会将 DEL 追加到缓冲区，确保最终的数据一致性。

Redis 主从模式中对过期键如何处理？

从库不会进行过期扫描，即使库中 key 过期，如果有客户端访问从库，仍然能拿到过期数据。从库的过期删除依赖主节点的控制，主节点 key 到期后，会在 AOF 文件追加 DEL 命令，并同步到所有从节点，从库执行 DEL 来删除过期的 key。

复习 Redis Day3：Redis 的应用

在这里插入图片描述

缓存雪崩、缓存击穿、缓存穿透的现象解释及解决办法？

缓存雪崩
指的是大量热点数据同时过期或 Redis 宕机，此时恰有大量客户端请求访问热点数据，请求在缓存中找不到对应的数据便会去数据库当中查找，数据库的压力骤增，有可能会崩溃，从而导致整个服务崩溃。

缓存雪崩的解决办法如下：

均匀设置热点数据的过期时间，避免出现同时过期的现象；
访问数据库重建缓存时加锁，降低数据库的压力；
Redis 宕机时，采用服务熔断或限流机制，暂停业务应用对缓存服务的访问，直接返回错误。等到 Redis 服务恢复后再上线服务，或限制访问数据库的用户量。

缓存击穿
指的是热点数据突然过期，导致客户端请求直接击穿缓存到达数据库，导致数据库崩溃。

缓存击穿的解决办法如下：

不为热点数据设置过期时间；
与缓存雪崩的解决办法类似，访问数据库重建热点数据的缓存时加锁。

缓存穿透
指的是大量无效的请求访问缓存中不存在的数据，导致请求继续前往数据库查找，导致数据库的压力上升。

缓存穿透的解决办法如下：

在缓存中为不存在的请求设置默认值，避免请求直接查找数据库；
将频繁恶意访问的用户拉入黑名单；

如何保证数据库和缓存的一致性？

普通方案

确保数据库和缓存一致性的普通方案包括 Cache-Aside、Write Through 和 Write Behind。

Cache Aside

读操作：如果缓存当中有数据，直接读取；如果缓存中没有数据，就到数据库查询并放到缓存当中；
写操作：先将数据持久化到数据库，再让缓存失效；

Cache Aside 的优点是简单易实现，适合读多写少的场景。

Write Through
所有写操作均同步更新数据库和缓存，适用于需要强一致性配置的数据。

Write Behind
写操作会直接更新缓存，再由缓存自行批量异步地更新数据库。该方案的速度很快，但是可能会导致数据不一致，适用于允许数据丢失的高吞吐场景。

进阶方案

在分布式系统中确保数据库和缓存的一致性需要进阶的技术方案。

双删策略 + 延迟队列

当客户端的写请求到达服务器时，服务器会进行第一次缓存删除，然后发送一个延迟删除的消息到 MQ 当中，之后到数据库对记录进行更新，完成数据的修改。MQ 在延迟时间（延迟时间应该大于主从复制的时间，这样能够确保主从复制的脏数据一定被删除）到之后，会第二次到缓存当中对数据进行删除，这样可以确保第一次缓存删除后以及数据库更新之前，如果「有读请求到数据库中重建缓存」或是「通过主从复制更新了缓存」，新的脏数据可以确保被删除掉。

在双删策略下，缓存不会主动重建，而是当读请求到来时，服务器到数据库中查找数据并重建缓存，可以确保在分布式系统中缓存与数据库的一致性。

基于 binlog 的最终一致性方案

基于 MySQL binlog 的最终一致性方案是目前企业中最可靠的数据库与缓存同步策略之一。具体来说，数据库的 binlog 就像是一个“操作日记本”，记录了所有数据变更，不同系统只需要订阅并重放 binlog，就可以逐步同步数据。

具体的实现步骤如下：

主库执行写操作，自动生成 binlog；
中间件（如 Canal）持续抓取 binlog；
将 binlog 的二进制日志翻译为可读事件；
通过消息队列将事件广播到包括缓存在内的所有订阅方；
各系统（缓存/搜索/统计）按顺序消费事件，但允许处理速度不同。

最终一致性保障：

顺序性：事件携带时间戳，消费端可以按序处理；
重试机制：失败的事件会重新投递直到成功；
幂等机制：即使重复收到相同事件，处理的结果仍然不变。

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

重试机制
引入消息队列，将删除操作封装为消息事件，使用支持持久化的消息队列（Kafka / RocketMQ）来存储事件，让事件的消费者来完成缓存的删除。引入消息队列并将删除缓存的操作封装为消息之后，即使消费者崩溃，消息也不会丢失。

基于 binlog 的最终一致性
所有删除操作先记录到 binlog 日志当中，后台进程持续消费日志执行删除，定期检查日志和缓存状态。

针对业务一致性要求高的场景，如何确保缓存与数据库的一致性？

缓存更新策略

Cache-Aside（旁路缓存）：读数据时，先读缓存，未命中则读数据库然后回填缓存；写数据时，先更新数据库，再删除缓存（而非更新缓存）。
Read/Write-Through：依赖于缓存组建，需要缓存具备一定的一致性能力，比如 Redis 企业版。具体来说，在写时，直接写缓存，依赖缓存组件将写入的数据同步更新到数据库；在读时，如果缓存未命中，仍然由缓存组建加载数据库数据回填缓存并返回数据。

延迟双删策略
延迟双删策略的具体步骤如下：

服务端针对客户端发送过来的写请求，首先删除缓存，然后发送一条延迟消息到 MQ；
之后修改数据库当中的数据；
MQ 延迟到期，再一次删除缓存当中的数据，以应对并发读导致的旧数据回填。

需要注意的是，延迟双删策略不会回填缓存，仍然依赖于读时的缓存回填。延迟双删策略结合消息队列实现二次删除，以应对并发读的旧数据回填问题（具体来说，这个问题会发生在写请求删除缓存之后，修改数据库之前，如果这个时候有另一个并发的读请求，它会访问数据库并读取还没有写入的旧数据，回填缓存导致数据不一致，通过消息队列延迟双删确保最终一致）。

基于事务消息确保最终一致性
具体步骤如下：

数据库更新后，发送事务消息到 MQ；
MQ 在消费端删除或更新缓存。

基于事务消息确保一致性的优点在于可以通过 MQ 确保最终一致性，该思想和延迟双删很像，但延迟双删是明确在第一次缓存删除后将消息发送给 MQ 进行二次缓存删除，而基于事务消息的最终一致性是在数据库当中记录更改后通过 MQ 修改或删除缓存。

该技术的关键点在于：

需处理消费者消费消息失败（重试 + 死信队列）；
需保证消息顺序性；

数据订阅与监听
具体步骤如下：

通过数据库 binlog 监听（MySQL + Canal）捕获变更事件；
变更事件会发送到消息队列，由订阅了该事件的消费者更新或删除缓存。

该方法的优点在于：对业务代码无入侵，适用于复杂业务场景。
该方法的挑战在于：需要解决 binlog 解析带来的延迟与顺序性问题。

分布式锁
分布式锁的应用场景是在高并发场景下，强行串行化数据库与缓存操作。

它的实现如下：

写操作前获取分布式锁（如 Redis Redlock）；
更新数据库后删除缓存，再释放锁。

基于分布式锁确保强一致性的方案会牺牲一定的并发性。

如何避免缓存失效？

在业务刚上线时，可以进行「缓存预热」，也就是提前把数据缓存起来，而不是等待用户访问时才查数据库并放回缓存。

业务上线后，可以开一个后台线程检查缓存是否有效，检测到缓存失效，可以立马去数据库查数据并放回缓存。

或者当业务线程发现缓存失效后，通过消息队列发送消息给后台线程更新缓存，后台线程收到消息后，在更新缓存之前可以先检查缓存是否存在，存在就不执行放回操作（缓存存在的原因可能是后台线程消费消息之前，已经有读请求到数据库查找数据并放回缓存了），否则就读数据库并放回缓存。

如何实现延迟队列？

使用 ZSet，ZSet 有一个 Score 属性可以存储延迟执行的事件。使用 zadd score1 value1，再利用 zrangebyscore 查询符合条件的待处理任务，循环执行队列当中的任务。

如何设计一个缓存策略，以动态缓存热点数据呢？

「与基于 Redis 实现的热度随时间下降的评价系统，具体实现可以参考《Redis 实现》第一章最后那一部分的实操」。

通过数据最新访问时间来做排名，并过滤掉不常访问的数据，只留下经常访问的数据。比如基于数据的访问量来增加当前数据在 Redis ZSet 当中的分数，通过 zadd 来实现。最后通过 zrange 来获取排名靠前的数据。

Redis 实现分布式锁？

为什么需要分布式锁？
在分布式系统中，多个节点或服务需要协调对共享资源的互斥访问（比如在「秒杀系统」中，针对同一个热点商品，不能超卖，因此需要使用分布式锁来确保库存的一致性）。Redis 分布式锁通过一个全局可见的共享存储实现跨进程/跨节点的互斥控制。

如何实现分布式锁？
核心命令：使用 SET key unique_value NX PX timeout 命令。

NX：仅当 key 不存在时设置成功（确保互斥性）；
PX：设置锁的过期时间（避免死锁）；
unique_value：唯一标识（UUID），确保只有锁的持有者能够释放锁。

释放锁时，通过 Lua 脚本确保原子性，检验 unique_value 并删除 key：

if redis.call("get", KEYS[1]) == ARGV[1] thenreturn redis.call("del", KEYS[1])
elsereturn 0
end

关键问题与解决方案
1. 如何避免死锁？
在加分布式锁时必须设置锁的过期时间 PX，即使业务逻辑异常也可以到期释放。但存在的问题是需要权衡锁的过期时间，过期时间过短可能会导致业务没有处理完，锁就失效了，时间过长会导致资源阻塞。

2. 如何防止误删其他客户端的锁？
释放锁时需要校验 unique_value（如 UUID），只有持有者才能删除。删除时通过 lua 脚本确保校验与删除操作的原子性。

3. 锁超时和业务执行时间冲突怎么办？
可以通过引入锁续期机制（Watchdog）。具体来说，客户端获取锁后，会启动一个后台线程，定期检查锁是否被持有，并自动延长锁的过期时间。

在实操中，可以使用 lua 脚本确保续期的一致性（校验唯一值 + 延长过期时间）：

RLock lock = redisson.getLock("myLock");
lock.lock()
try {// 业务逻辑
} finally {lock.unlock()// ⬆️释放锁并停止续期
}

4. Redis 单点故障问题？
Redis 的单点故障问题指的是 Redis 宕机时，锁丢失会导致多个客户端同时持有锁，破坏互斥性。

解决单点故障的方案有两种，分别是使用 RedLock 算法（多节点容错）以及 Redis Sentinel/Cluster 高可用方案。具体来说：

RedLock 算法
RedLock 算法的核心思想是向多个独立的 Redis 主节点申请锁，多数节点成功才能加锁。

实现步骤如下：

客户端向 5 个 Redis 节点依次发送 SET key unique_value NX PX timeout 命令；
计算获取锁的总耗时（需要小于锁的超时时间）；
若成功获取多数节点，则加锁成功；
若失败，向所有节点发送释放锁请求。

Redis Sentinel/Cluster 高可用方案

Sentinel：主节点宕机时自动切换从节点为主节点，但主从切换期间可能会导致锁丢失；
Redis Cluster：数据分片存储，但分布式锁的 key 需要强制路由到同一个节点；
局限性：Redis 主从复制是异步的，不能保证强一致性，因此 RedLock 仍然是更可靠的方案。

5. 高并发下如何处理锁竞争？
指的是大量客户端同时竞争同一把锁，导致系统吞吐量下降，甚至雪崩。

可选的解决方案有：
1. 减小锁的粒度

分片锁：以具体的业务为维度对锁的粒度进行细化（如按用户 ID、订单 ID 进行分片）。
读写锁分离：区分读锁和写锁，提高并发度。

2. 等待队列与公平锁

队列化请求：客户端获取锁失败后进入队列等待，避免频繁重试。
公平锁实现：Redisson 公平锁会基于 Redis 的 List 数据结构实现 FIFO 队列，确保先到先得。

3. 超时与重试机制

非阻塞尝试：使用 tryLock() 设置最大等待时间，避免无限阻塞。
随机退避：在重试时引入随机延迟，避免活锁。

对比其他分布式锁方案
为什么选 Redis 而不是 zookeeper 或 etcd？

Redis 的优势：性能高（在内存操作，适合高频锁竞争场景）；实现简单，社区成熟。
Zookeeper / etcd 适用场景：强一致性要求高，但性能较低，需要维护会话。

用一句话介绍 Redis 分布式锁
Redis 分布式锁通过一个全局可见的共享存储实现跨进程或跨节点的互斥控制。具体来说，Redis 分布式锁的核心是通过 SET key unique_value NX PX timeout 命令实现互斥性和防死锁。释放时需要通过 lua 脚本检验 unique_value 这个唯一标识，避免误删。使用 lua 脚本的目的是确保检验操作与解锁操作的一致性。实际应用中需要解决锁续期、单点故障、高并发竞争等问题。锁续期可以通过在加锁时开启后台线程监控业务进度来解决；单点故障可以使用 RedLock 算法来解决；高并发竞争可以通过对锁按业务粒度进行分片，或引入等待队列机制来解决。Redis 分布式锁相较于 zookeeper/etcd 这类锁而言性能更好，但是一致性保障稍弱，在实际应用中需要权衡。

使用 Redis 实现分布式锁的优缺点？

优点：性能高效，实现方便，可以通过 RedLock 避免单点故障；
缺点：Redis 分布式锁的超时时间不好把控（可以通过 Watchdog 机制来缓解）。此外，Redis 主从复制是异步的，这会导致分布式锁的不可靠性。如果 Redis 主节点在获取分布式锁之后，还没来得及同步到从节点就宕机了，此时新的 Redis 主节点依然可以分发分布式锁，这会导致多个应用服务同时获取锁，导致数据不一致。

解决由于 Redis 主从复制异步可能带来的数据不一致的问题的方案仍然是使用 RedLock 算法，因为 RedLock 算法可以避免单点故障，即使多个主节点宕机了，只要部分节点仍然存活，锁依然有效；并且 RedLock 不依赖主从辅助，各主节点独立决策。

Redis 如何解决集群模式下分布式锁的可靠性？

通过 RedLock 算法。方才已经提到，RedLock 算法会在客户端请求分布式锁时，向多个 Redis 主节点发送加锁请求，当多数节点（ $2/ N + 1$ ）时加锁才算成功，这样可以保证 Redis 发生单点故障时，分布式锁仍然可用。

RedLock 算法加锁步骤：

客户端获取当前时间（ $t_1$ ）；
客户端按顺序依次向 $N$ 个 Redis 主节点发送加锁请求 SET key unique_value NX PX timeout；
一旦客户端从超过半数的 Redis 主节点获取分布式锁，那么记录当前时间（ $t_2$ ），然后计算整个加锁过程的总时耗（ $t_2 - t_1$ ），如果 $t_2 - t_1$ 小于锁的过期时间，则认为客户端加锁成功，否则认为加锁失败。

不难看出，加锁成功需要同时满足：

超过半数 Redis 主节点同意加锁；
加锁的总时耗小于分布式锁的过期时间。

如果加锁失败，那么客户端将向所有 Redis 主节点发送释放锁的操作，通过 lua 脚本完成。

Redis 管道有什么用？管道与事务有什么区别？

Redis 的管道（Pipeline）和事务（Transaction）都是用于批量执行多个命令的机制，但是二者的设计目标与使用场景有本质区别。

Redis 管道（Pipeline）

特点

优化网络性能：客户端批量发送多个命令到 Redis 服务端，服务端批量处理命令并将结果统一返回给客户端，减少网络往返时间（RTT）开销；
非原子性：管道中的命令按顺序执行，但执行期间可能被其他客户端命令插入。
某条命令失败不会影响后续命令的执行。

工作原理
客户端将多个命令一次性打包发送给 Redis 服务器，服务器按顺序执行并返回结果。

使用场景

批量数据操作；
高吞吐需求：需要快速执行大量非关联命令的场景（如日志记录）。

Redis 事务（Transaction）

特点

原子性保证：通过 MULTI 和 EXEC 将多个命令打包为原子操作。
乐观锁支持：结合 WATCH 实现乐观锁，监控键值变化。
性能相较于 Pipeline 更低，因为需要等到 EXEC 统一执行。
语法错误会导致整个事务失败。运行时错误不影响其他命令，因此 Redis 的错误「无回滚机制」。

工作原理
事务队列：MULTI 后的命令进入队列，EXEC 时一次性顺序执行。

使用场景

需要原子性的操作：例如转账操作；
并发控制：通过 WATCH 实现乐观锁，避免数据竞争。

Lua 脚本 vs. Transaction

特性	事务	Lua 脚本
原子性	命令队列原子执行，从 `MULTI` 开始直到 `EXEC`	脚本整体原子执行
灵活性	有限（仅 Redis 命令）	高（支持条件判断、循环等）
错误处理	无回滚	脚本错误会回滚
性能	高	更高（减少网络开销）

最佳实践

优先使用 lua 脚本；
避免事务中包含耗时操作；
合理使用 WATCH；
错误处理。

Redis 事务与 MySQL 事务的区别？

核心区别对比

对比维度	Redis 事务	MySQL 事务
原子性	部分原子性：命令队列整体执行，如果有语法错误，整个队列执行失败；运行时出现的命令错误不会阻止其他命令执行	完全原子性：事务当中的索引操作要么全部成功，要么全部失败
隔离性	天然串行化隔离（事务执行期间不会被其他操作打断，原因在于 Redis 是单线程执行的）	支持多级别隔离（如读未提交、读已提交、可重复读、串行化）
持久性	依赖 Redis 的持久化配置（RDB/AOF），可能会出现数据丢失，AOF-always 是最安全的	通过 Redo Log 确保持久化，事务只要提交数据就不会丢失
回滚机制	Redis 事务无回滚机制	MySQL 事务可以通过 Rollback 回滚
锁机制	乐观锁，通过 `WATCH` 实现	悲观锁（表锁、行锁等）
功能复杂度	简单，仅仅是事务中命令的批量执行	复杂
适用场景	高并发简单操作	强一致业务