1.全面解析redis-RDB与AOF持久化机制

Redis之所以能够提供高速读写操作是因为数据存储在内存中，但这也带来了一个风险，即在服务器宕机或断电的情况下，内存中的数据会丢失。为了解决这个问题，Redis提供了持久化机制来确保数据的持久性和可靠性。

Redis持久化机制：

ⅰ.RDB(Redis Data Base) ：内存快照

ⅱ.AOF(Append Only File)： 增量日志

混合持久化：RDB + AOF

RDB持久化

在指定的时间间隔内将内存中的数据集快照写入磁盘，RDB是内存快照（内存数据的二进制序列化形式）的方式持久化，每次都是从Redis中生成一个快照进行数据的全量备份。

RDB持久化流程：

 

RDB持久化方案进行备份时，Redis会单独fork一个子进程来进行持久化，会将数据写入一个临时文件中，持久化完成后替换旧的RDB文件。

在整个持久化过程中，主进程（为客户端提供服务的进程）不参与IO操作，这样能确保Redis服务的高性能，RDB持久化机制适合对数据完整性要求不高但追求高效恢复的使用场景。

RDB触发规则

手动触发

save：

阻塞当前 Redis进程，直到RDB持久化过程完成，如果内存实例比较大会造成长时间阻塞，尽量不要使用这方式

bgsave：

Redis主进程fork创建子进程，由子进程完成持久化，阻塞时间很短（微秒级）

自动触发

配置触发：

• 在Redis安装目录下的redis.conf配置文件中搜索 /snapshot即可快速定位，配置文件默认注释了下面三行数据，通过配置规则来触发RDB的持久化，需要开启或者根据自己的需求按照规则来配置。

 

save 3600 1 -- 3600 秒内有1个key被修改，触发RDB
save 300 100 -- 300 秒内有100个key被修改，触发RDB
save 60 10000 -- 60 秒内有10000个key被修改，触发RDB

shutdown触发：

• shutdown触发Redis的RDB持久化机制非常简单，我们在客户端执行shutdown即可。

 

flushall触发:

• flushall清空Redis所有数据库的数据（16个库数据都会被删除）（等同于删库跑路）

 

优点：

• 性能高：RDB持久化是通过生成一个快照文件来保存数据，因此在恢复数据时速度非常快。
• 文件紧凑：RDB文件是二进制格式的数据库文件，相对于AOF文件来说，文件体积较小。

缺点：

• 可能丢失数据：由于RDB是定期生成的快照文件，如果Redis意外宕机，最近一次的修改可能会丢失。

TIPS

Redis持久化默认开启为RDB持久化

AOF持久化

AOF持久化需要手动修改conf配置开启。

AOF持久化流程：

 

AOF持久化方案进行备份时，客户端所有请求的写命令都会被追加到AOF缓冲区中，缓冲区中的数据会根据Redis配置文件中配置的同步策略来同步到磁盘上的AOF文件中，同时当AOF的文件达到重写策略配置的阈值时，Redis会对AOF日志文件进行重写，给AOF日志文件瘦身。Redis服务重启的时候，通过加载AOF日志文件来恢复数据。

AOF配置：

AOF默认不开启，默认为appendonly no，开启则需要修改为appendonly yes

 

关闭AOF+RDB混合模式，设为no：

 

AOF同步策略：

 

appendfsync always：

• • 每次Redis写操作，都写入AOF日志，非常耗性能的。

appendfsync everysec

• • 每秒刷新一次缓冲区中的数据到AOF文件，这个Redis配置文件中默认的策略，兼容了性能和数据完整性的折中方案，这种配置，理论上丢失的数据在一秒钟左右

appendfsync no

• • Redis进程不会主动的去刷新缓冲区中的数据到AOF文件中，而是直接交给操作系统去判断，这种操作也是不推荐的，丢失数据的可能性非常大。

AOF修复功能：

redis 7版本，AOF文件存储在appendonlydir文件下，base是基准文件，incr是追加数据。

 

先存入三条数据，然后破坏incr结尾的文件内容，末尾加上bAIli

 

 

重新启动报错：

 

使用redis-check-aof --fix
appendonlydir/appendonly.aof.1.incr.aof 对AOF日志文件进行修复

 

观察数据可以知道，丢失了cc-key值。这种丢失是被允许的。

AOF重写

重写其实是针对AOF存储的重复性冗余指令进行整理，比如有些key反复修改，又或者key反复修改后最终被删除，这些过程中的指令都是冗余且不需要存储的。

自动重写：

当AOF日志文件达到阈值时会触发自动重写。

重写阈值配置：

 

• auto-aof-rewrite-percentage 100：当AOF文件体积达到上次重写之后的体积的100%时，会触发AOF重写。
• auto-aof-rewrite-min-size 64mb：当AOF文件体积超过这个阈值时，会触发AOF重写。

当AOF文件的体积达到或超过上次重写之后的比例，并且超过了最小体积阈值时，Redis会自动触发AOF重写操作，生成一个新的AOF文件。

手动重写：bgrewriteaof

正常启动后存在三个文件：

 

通过set命令存储三条数据，最后在修改aa数据，然后手动重写：

 

观察结果可以得知key值aa历史轨迹已经被删除

 

优点：

• 数据更加可靠：AOF持久化记录了每个写命令的操作，因此在出现故障时，可以通过重新执行AOF文件来保证数据的完整性。
• 可以保留写命令历史：AOF文件是一个追加日志文件，可以用于回放过去的写操作。

缺点：

• 文件较大：由于记录了每个写命令，AOF文件体积通常比RDB文件要大。
• 恢复速度较慢：当AOF文件较大时，Redis重启时需要重新执行整个AOF文件，恢复速度相对较慢。

混合持久化

Redis4.0版本开始支持混合持久化，因为RDB虽然加载快但是存在数据丢失，AOF数据安全但是加载缓慢。

混合持久化通过aof-use-rdb-preamble yes开启，Redis 4.0以上版本默认开启

 

开启混合持久化之后：appendonlydir文件下存在一个rdb文件与一个aof文件

 

存入数据，然后执行bgrewriteaof重写文件。

 

 

总结

• 推荐两者均开启
• 如果对数据不敏感，可以选单独用RDB
• 不建议单独用AOF，因为可能会出现Bug
• 如果只是做纯内存缓存，可以都不用

 

2.Redis缓存击穿、缓存雪崩、缓存穿透

缓存击穿、缓存雪崩和缓存穿透是我们在日常开发与手撕面试官过程中必须battle的常见问题，下面我会解释它们的含义与解决方案。

1.缓存击穿（Cache Miss）

什么是缓存击穿？

缓存击穿是指在高并发访问下，一个热点数据失效时，大量请求会直接绕过缓存，直接查询数据库，导致数据库压力剧增。

通常情况下，缓存是为了减轻数据库的负载，提高读取性能而设置的。当某个特定的缓存键（key）失效后，在下一次请求该缓存时，由于缓存中没有对应的数据，因此会去数据库中查询，这就是缓存击穿。

解决方案：

• 合理的过期时间：设置热点数据永不过期，或者设置较长的过期时间，以免频繁失效。
• 使用互斥锁：保证同一时间只有一个线程来查询数据库，其他线程等待查询结果。

2.缓存雪崩（Cache Avalanche）

什么是缓存雪崩？

缓存雪崩是指在大规模缓存失效或者缓存宕机的情况下，大量请求同时涌入数据库，导致数据库负载过大甚至崩溃的情况。

正常情况下，缓存中的数据会根据过期时间进行更新，当大量数据同时失效时，下一次请求就会直接访问数据库，给数据库带来巨大压力。

解决方案：

• 合理的过期时间：为缓存的过期时间引入随机值，分散缓存过期时间，避免大规模同时失效。或者是粗暴的设置热点数据永不过期
• 多级缓存：使用多级缓存架构，如本地缓存 + 分布式缓存，提高系统的容错能力。
• 使用互斥锁：保证同一时间只有一个线程来查询数据库，其他线程等待查询结果。
• 高可用架构：使用Redis主从复制或者集群来增加缓存的可用性，避免单点故障导致整个系统无法使用。

3.缓存穿透（Cache P.NETration）

什么是缓存穿透？

缓存穿透是指恶意请求查询一个不存在于缓存和数据库中的数据，导致每次请求都直接访问数据库，从而增加数据库的负载。

攻击者可以通过故意构造不存在的 Key 来进行缓存穿透攻击。

解决方案：

• 缓存空对象：对于查询结果为空的情况，也将其缓存起来，但使用较短的过期时间，防止攻击者利用同样的 key 进行频繁攻击。
• 参数校验：在接收到请求之前进行参数校验，判断请求参数是否合法。
• 布隆过滤器：判断请求的参数是否存在于缓存或数据库中。

3.什么是Redis哨兵机制

为什么需要哨兵机制？

Redis的主从复制主要用于实现数据的冗余备份和读分担，并不是为了提供高可用性。因此在系统高可用方面，单纯的主从架构无法很好的保证整个系统高可用。比如说：

 

• 需要人工介入：需要人工介入进行主节点切换。当主节点发生故障时，主从复制无法自动进行主节点的切换。需要管理员手动干预，修改配置将一个从节点提升为新的主节点。这增加了人工操作的复杂性和潜在的延迟。
• 主节点写能力有限：主节点的写能力受限于单个节点。在主从复制中，所有写操作都必须发送给主节点处理，然后再同步到从节点。这导致主节点成为写入瓶颈，其写能力受限于单个节点的硬件和性能。如果负载过大，主节点的响应时间可能会增加，影响整体性能。
• 单机节点存储能力有限：存储能力受限于主节点的容量。在主从复制中，所有数据都存储在主节点上，从节点仅用于提供读服务。这限制了整个系统的存储能力，因为主节点的存储容量有限。如果数据量增长过快或存储需求增加，主节点的存储容量可能会成为瓶颈。

因此通常是使用Redis哨兵机制或Redis集群模式来提高整个系统的可用性、扩展性和负载均衡能力。

哨兵机制(sentinel)的原理

Redis哨兵机制是通过在独立的哨兵节点上运行特定的哨兵进程来实现的。这些哨兵进程监控主从节点的状态，并在发现故障时自动完成故障发现和转移，并通知应用方，实现高可用性。

以下是哨兵机制的工作原理：

 

a.哨兵选举：

在启动时，每个哨兵节点会执行选举过程，其中一个哨兵节点被选为领导者（leader），负责协调其他哨兵节点。

ⅰ.选举过程：

• 每个在线的哨兵节点都可以成为领导者，每个哨兵节点会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者；
• 当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
• 如果哨兵发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举。

b.监控主从节点：

哨兵节点通过发送命令周期性地检查主从节点的健康状态，包括主节点是否在线、从节点是否同步等。如果哨兵节点发现主节点不可用，它会触发一次故障转移。

c.故障转移：

一旦主节点被判定为不可用，哨兵节点会执行故障转移操作。它会从当前的从节点中选出一个新的主节点，并将其他从节点切换到新的主节点。这样，系统可以继续提供服务而无需人工介入。

ⅰ.故障转移过程：

• • 由Sentinel节点定期监控发现主节点是否出现了故障： sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了。
  • 确认主节点：
  • 过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
  • 选择从节点优先级最高的
  • 选择复制偏移量最大，此指复制最完整的从节点

当主节点出现故障， 由领导者负责处理主节点的故障转移。

d.客户端重定向：

哨兵节点会通知客户端新的主节点的位置，使其能够与新的主节点建立连接并发送请求。这确保了客户端可以无缝切换到新的主节点，继续进行操作。

此外，哨兵节点还负责监控从节点的状态。如果从节点出现故障，哨兵节点可以将其下线，并在从节点恢复正常后重新将其加入集群。

客观下线

当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（选举）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线。

总结

redis哨兵的作用:

• 监控主数据库和从数据库是否正常运行。
• 主数据库出现故障时，可以自动将从数据库转换为主数据库，实现自动切换。

4.说一说Redis的过期策略和内存淘汰策略

 

Redis的过期策略

a.惰性删除（Lazy expiration）

• 当客户端尝试访问某个键时，Redis会先检查该键是否设置了过期时间，并判断是否过期。
• 如果键已过期，则Redis会立即将其删除。这就是惰性删除策略。

该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。

b.定期删除（Active expiration）

• Redis会每隔一段时间（默认100毫秒）随机检查一部分设置了过期时间的键。
• 定期过期策略通过使用循环遍历方式，逐个检查键是否过期，并删除已过期的键值对。

通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果

Redis中同时使用了惰性过期和定期过期两种过期策略。

• 假设Redis当前存放20万个key，并且都设置了过期时间，如果你每隔100ms就去检查这全部的key，CPU负载会特别高，最后可能会挂掉。
• 因此redis采取的是定期过期，每隔100ms就随机抽取一定数量的key来检查和删除的。
• 但是呢，最后可能会有很多已经过期的key没被删除。这时候，redis采用惰性删除。在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间并且已经过期了，此时就会删除。

需要注意如果定期删除漏掉了很多过期的key，然后也没走惰性删除。就会有很多过期key积在内存中，可能会导致内存溢出，或者是业务量太大，内存不够用然后溢出了，为了应对这个问题，Redis引入了内存淘汰策略进行优化。

Redis的内存淘汰策略

内存淘汰策略允许Redis在内存资源紧张时，根据一定的策略主动删除一些键值对，以释放内存空间并保持系统的稳定性。

a.noeviction（不淘汰策略）

当内存不足以容纳新写入数据时，Redis 将新写入的命令返回错误。这个策略确保数据的完整性，但会导致写入操作失败。

b.volatile-lru（最近最少使用）

从设置了过期时间的键中选择最少使用的键进行删除。该策略优先删除最久未被访问的键，保留最常用的键。

c.volatile-ttl（根据过期时间优先）

从设置了过期时间的键中选择剩余时间最短的键进行删除。该策略优先删除剩余时间较短的键，以尽量保留剩余时间更长的键。

d.volatile-random（随机删除）

从设置了过期时间的键中随机选择一个键进行删除。

e.allkeys-lru（全局最近最少使用）

从所有键中选择最少使用的键进行删除。无论键是否设置了过期时间，都将参与淘汰。

f.allkeys-random（全局随机删除）

从所有键中随机选择一个键进行删除。