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

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

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

缓存穿透

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

解决办法

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

缓存击穿

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

解决办法

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

缓存雪崩

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

解决办法

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

RDB和AOF

介绍RDB

RDB（Redis Database）

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

介绍AOF

AOF（Append Only File）

1. 概念：
   ○ AOF记录每个写操作指令，并将其追加到日志文件的末尾。这意味着AOF文件是一种日志文件，记录了如何从空数据库开始逐步构建出当前的数据状态。
2. 工作方式：
   ○ 每当Redis执行一个会改变数据的命令时，该命令会被追加到AOF文件的末尾。Redis还提供不同的AOF重写策略，可以定期压缩AOF日志。
3. 优点：
   ○ 数据安全性：AOF可以配置为每个写命令立即写入硬盘，减少数据丢失的风险。
   ○ 更强的持久性保证：与RDB相比，AOF在系统崩溃时丢失的数据更少。
4. 缺点：
   ○ 文件大小：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