Redis击穿、穿透、雪崩介绍、以及解决方法、RDB和AOF的介绍，以及save和bgsave的区别-CSDN博客

本文链接：https://blog.csdn.net/weixin_47705408/article/details/135375081

Redis击穿、穿透、雪崩介绍、以及解决方法、RDB和AOF的介绍

Redis是基于单线程模型时，通常是指其核心数据操作（键值对的读取、写入、删除等）是在单个线程上顺序执行的。这意味着在任何给定时间点，处理客户端命令的是单个线程。
比如（RDB）bgsave就是开启一个子线程去向文件中写入数据

缓存穿透

当缓存中没有请求的数据，而请求的数据在数据库中也不存在时，这些无效的请求会穿透缓存直接请求到数据库，如果大量这样的请求发生，会给数据库带来很大的压力。缓存穿透的问题主要是因为缓存系统没有办法识别出这些无效的请求，导致每次都要去数据库查询。

解决办法

布隆过滤器：
○ 使用布隆过滤器，将所有可能存在的数据哈希到一个足够大的位数组中。当一个新的请求进来时，先通过布隆过滤器检查这个数据是否可能存在。如果布隆过滤器认为这个数据不存在，则直接返回，不再查询数据库。
缓存空对象：
○ 当查询数据库发现数据不存在时，将这个查询条件对应的空对象缓存起来，并设置一个较短的过期时间。这样，当同样的查询再次发生时，可以直接从缓存中获取到这个空对象，避免对数据库的查询。
严格的参数校验：
○ 在接口层增加严格的参数校验，如合理的长度限制，格式校验等，不合法的请求直接拒绝，减少对后端系统的压力。
限流和降级：
○ 对于访问频率异常高的访问，实施限流措施，比如限制每秒请求的数量。或者在检测到攻击时，对部分服务进行降级。
接口鉴权：
○ 增加一定的接口鉴权机制，确保只有合法的用户或系统可以调用接口。

缓存击穿

一个高访问量的key突然失效（比如过期），导致所有的请求都直接打到数据库，这可能会给数据库带来很大的压力，甚至导致数据库崩溃。

解决办法

设置合理的过期时间：
○ 对于一些热点数据，可以设置较长的过期时间，或者不设置过期时间，而是定期更新缓存。
使用互斥锁：
○ 当一个key失效时，不是所有的请求都去加载数据库，而是使用锁或者其他同步机制，保证只有一个请求去加载数据库，其他请求等待。
永不过期：
○ 对于某些关键数据，可以选择让它们在缓存中永不过期。但这样做需要确保有机制定期更新这些数据，以保持数据的新鲜度。
二级缓存策略：
○ 实施二级缓存，即当一级缓存Redis击穿时，可以访问二级缓存（另一个缓存系统或者一组不同的缓存策略）。
预热缓存：
○ 在将key放入缓存之前，先进行缓存预热，即事先计算好缓存的值。
限流降级：
○ 当检测到缓存击穿时，可以实施限流措施，比如临时降低服务质量，限制用户访问频率等。
布隆过滤器：
○ 使用布隆过滤器来判断一个key是否存在于缓存中，这样可以在请求到达数据库之前，就避免了不必要的数据库访问。

缓存雪崩

大量的缓存同时失效（比如同一时间大量缓存到期,服务器宕机)，导致原本应该由缓存承载的请求全部转移到数据库上，造成数据库压力急剧增加，甚至可能导致数据库服务崩溃的现象。

解决办法

缓存数据的过期时间分散设置：
○ 不要让大量缓存在同一时间失效。可以在原有的过期时间基础上加上一个随机值，以分散不同缓存键的过期时间。
使用持久化存储作为缓存降级：
○ 当缓存不可用时，可以使用如硬盘这样的持久化存储作为缓存的降级方案，虽然速度较慢，但比直接访问数据库要快。
设置缓存更新锁：
○ 当缓存失效后，通过设置锁或者其他同步机制，保证同一时间只有一个请求去更新缓存，其他请求等待或者从备份缓存中获取数据。
提前更新缓存：
○ 在缓存到期之前，提前更新缓存数据。这可以通过后台定时任务来实现，避免缓存同时过期。
提高缓存服务的高可用性和容错性：
○ 使用集群或者分布式缓存，即使个别节点失败，也不会影响整体服务。
限流降级策略：
○ 在系统中实施限流降级策略，当监测到缓存层有问题时，自动切换到限流策略，确保系统的稳定性。
监控和报警机制：
○ 加强监控，当缓存命中率异常或访问压力异常时及时发出报警，由运维人员或自动化脚本进行处理。

RDB和AOF

介绍RDB

RDB（Redis Database）

概念：
○ RDB是一种快照式持久化方法。它在特定的间隔时间内执行数据集的时间点快照。
工作方式：
○ RDB通过创建当前数据库状态的副本来工作。这个过程可以定期进行，比如每隔几分钟，或者基于数据变更的次数（如每1000次键修改）。
优点：
○ 性能：RDB在保存数据时对Redis主进程的性能影响较小。
○ 紧凑的文件尺寸：RDB生成的文件紧凑且易于传输。
○ 灾难恢复：由于RDB文件是数据集的完整副本，它们非常适合做全量数据备份，用于灾难恢复。
缺点：
○ 数据丢失风险：如果Redis崩溃，自上次快照以来的所有数据都会丢失。
○ 快照性能开销：虽然RDB对Redis性能影响较小，但在大数据集的情况下，快照操作可能会对性能产生明显影响。

介绍AOF

AOF（Append Only File）

概念：
○ AOF记录每个写操作指令，并将其追加到日志文件的末尾。这意味着AOF文件是一种日志文件，记录了如何从空数据库开始逐步构建出当前的数据状态。
工作方式：
○ 每当Redis执行一个会改变数据的命令时，该命令会被追加到AOF文件的末尾。Redis还提供不同的AOF重写策略，可以定期压缩AOF日志。
优点：
○ 数据安全性：AOF可以配置为每个写命令立即写入硬盘，减少数据丢失的风险。
○ 更强的持久性保证：与RDB相比，AOF在系统崩溃时丢失的数据更少。
缺点：
○ 文件大小：AOF文件通常比RDB文件大，因为它存储了更多的详细操作。
○ 性能：根据配置，AOF可能会比RDB慢，尤其是在高写入负载下。
综合使用 RDB 和 AOF
在实践中，许多Redis用户选择同时使用RDB和AOF，以结合两者的优点。例如，可以使用RDB进行定期的全量备份，同时使用AOF来记录最近的写操作，这样即使在系统崩溃的情况下也能保证数据的完整性和可恢复性。

RDB持久化
持久化机制

save 900 1  # 如果在900秒内至少有一个key被修改，则执行bgsave，如果是save"" 则表示禁用RDB
save 300 10
save 60 10000

RDB的bgsave和save的的比较

相同点:

bgsave和save命令都是保存数据快照(持久化数据)

不同点:
save操作

save 是一个同步保存操作，它会阻塞所有其他客户端的请求直到保存操作完成。
在save命令执行期间，Redis不响应任何其他命令（阻塞其他操作）

bgsave操作

BGSAVE 是一个异步保存操作。执行bgsave时，Redis会派生（fork）一个新的子进程来创建数据快照，父进程（即Redis服务器）则可以继续处理客户端请求，因此在使用的使用bgsave会比save使用的更加频繁。
BGSAVE在进行快照时，由于进程复制（fork），会有短暂的内存使用增加，因为Redis需要复制当前进程的内存。这是操作系统的写时复制（copy-on-write）机制的一部分。

copy-on-write机制

初始状态 当一个父进程准备复制（fork）出一个子进程时，操作系统不会立即为子进程分配一个全新的内存区域。相反，子进程最初会共享父进程的内存页。
修改发生时 只有当父进程或子进程尝试修改这些共享的内存页时，操作系统才会为修改的部分分配新的内存空间。即，修改操作触发了“复制”。这样，修改后的数据被写入到新的内存页，而其他未修改的数据仍然共享(这也是上面RDB为什么必须在一定的时间内存在修改后才会触发保存的原因)。
节省资源这种方法节省了大量的内存和CPU资源，因为只有必要时才会复制内存，而不是在进程创建时就复制整个内存空间