过期策略和内存淘汰策略
过期策略
redis过期策略：定期删除+惰性删除。
定期删除： redis使用一个定时器来检查每个键是否已过期，默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。
这个默认时间是可以在Redis的配置文件中通过设置hz参数来改变的。
定时删除策略的优点是它可以确保过期键被及时删除。缺点是它可能会浪费一些 CPU 时间和内存，因为即使键在很长一段时间内没有被访问，仍然需要检查它是否过期。
惰性删除：惰性过期策略是指在访问键时检查它是否已过期。如果键已过期，则它将被删除。
惰性删除策略的优点是它可以最大限度地减少 CPU 时间和内存的浪费，因为只有在需要访问键时才会检查它是否过期。缺点是可能会导致一些键过期后仍然留在 Redis 中。
定期删除是集中处理，惰性删除是零散处理。
Redis默认使用惰性过期策略，但可以在配置文件中通过设置maxmemory-policy选项来选择不同的过期策略，例如volatile-ttl表示使用定时过期策略。
如果定期删除漏掉了很多过期 key，但也没有及时去查询，没有进行惰性删除，此时大量过期 key 堆积在内存里，导致 redis 内存块耗尽了，此时走内存淘汰策略。
内存淘汰策略
八大内存淘汰策略：
- volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。
- volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰。
- volatile-random：从已设置过期时间的数据集中任意选择数据淘汰。
- volatile-lfu：从已设置过期时间的数据集挑选使用频率最低的数据淘汰。
- allkeys-lru：从数据集中挑选最近最少使用的数据淘汰
- allkeys-lfu：从数据集中挑选使用频率最低的数据淘汰。
- allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
- no-enviction（驱逐）：禁止驱逐数据，默认策略。意思是当内存不足以容纳新入数据时，新写入操作就会报错，请求可以继续进行，线上任务也不能持续进行，采用no-enviction策略可以保证数据不被丢失。
执行原理：
删除失效主键（消极、积极、主动）
淘汰数据的量（为了避免频繁的触发淘汰策略，每次会淘汰掉一批数据，淘汰的数据的大小其实是和置换的大小来确定的，如果置换的数据量大，淘汰的肯定也多。）
置换策略（在执行增加数据时，Redis会检查内存使用，如果内存使用超过maxmemory，就会按照置换策略删除一些key）
持久化机制
在我们安装了redis之后，所有的配置都是在redis.conf文件中，里面保存了RDB和AOF两种持久化机制的各种配置。
持久化流程
（1）客户端向服务端发送写操作(数据在客户端的内存中)。
（2）数据库服务端接收到写请求的数据(数据在服务端的内存中)。
（3）服务端调用write这个系统调用，将数据往磁盘上写(数据在系统内存的缓冲区中)。
（4）操作系统将缓冲区中的数据转移到磁盘控制器上(数据在磁盘缓存中)。
（5）磁盘控制器将数据写到磁盘的物理介质中(数据真正落到磁盘上)。
RDB
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
RDB机制是通过把某个时刻的所有数据生成一个快照来保存，对于RDB来说，提供了三种触发机制实现这个过程：save、bgsave、自动化。
触发机制
1.save
该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。
执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。
2.bgsave
执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
| 命令 | save | bgsave |
|---|---|---|
| IO类型 | 同步 | 异步 |
| 是否阻塞 | 是 | 是（阻塞发生在fork） |
| 复杂度 | O（n） | O（n） |
| 优点 | 不会消耗额外内存 | 不阻塞客户端命令 |
| 缺点 | 阻塞客户端命令 | 需要fork消耗内存 |
3.自动化
自动触发是由我们的配置文件来完成的。在redis.conf配置文件中，里面有如下配置，我们可以去设置：
①save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。
默认如下配置：
1 | #表示900 秒内如果至少有 1 个 key 的值变化，则保存 |
不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。
②stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了
③rdbcompression ；默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。
④rdbchecksum ：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
⑤dbfilename ：设置快照的文件名，默认是 dump.rdb
⑥dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。
优势和劣势
优势：
①RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
②生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
③RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
劣势：
RDB快照是一次全量备份，存储的是内存数据的二进制序列化形式，存储上非常紧凑。当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。
AOF
全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。
AOF持久化原理
文件重写原理
AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。
重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
触发机制
AOF也有三种触发机制：
（1）每修改同步always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
（2）每秒同步everysec：异步操作，每秒记录 如果一秒内宕机，有数据丢失
（3）不同no：从不同步
| 命令 | always | everysec | no |
|---|---|---|---|
| 优点 | 不丢失数据 | 每秒一次fsync丢一秒数据 | 不用管 |
| 缺点 | IO开销较大，一般的sata盘只有几百TPS | 丢一秒数据 | 不可控 |
优点和缺点
优点:
①AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
②AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。③AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
④AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据
缺点:
①对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
②AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
③以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。
RDB和AOF对比
| 命令 | RDB | AOF |
|---|---|---|
| 启动优先级 | 低 | 高 |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 丢数据 | 根据策略决定 |
| 轻重 | 重 | 轻 |
两者通常结合使用
常见业务问题场景
缓存雪崩
缓存雪崩：是指缓存同一时间大面积失效，后面数据查询时都查询数据库，数据查询的压力全 部落到了数据库上，导致数据库短时间内承受大量的请求而down掉。
解决方案：
1.缓存数据的过期时间设置为随机，防止同一时间出现大批数据过期的现象；
2.将热点数据设置为永不过期；
3.如果并发量不是特别高，可以加入队列或者锁；
4.如果缓存数据库是分布式部署的，可以将热点的数据打散均匀分布到多个节点中。
缓存穿透
缓存穿透：是指缓存和数据库中都没有的数据，导致所有的请求全都落到数据库上，并且是并发量较高，当然也有可能是恶意攻击，造成数据库短时间内承受大量请求而挂掉。
解决方案：
1、给接口层增加校验，比如用户鉴权校验；
2、将空数据放到缓存中，设置key-null,同时设置短的缓存时间(如30秒)，这样可以防止攻击用 户反复用一个id暴力攻击；
3、采用布隆过滤器，将所有可能存在的数据哈希存到一个足够大的数据结构中，一些一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
缓存击穿
缓存击穿：是指缓存中没有或者已经到期但是数据库中有的数据，这时由于并发用户特别多，同时在缓存中又没有读到数据，所以直接去数据库中取数据，引起数据库压力瞬间增大。和缓存雪崩不同的是，缓存击穿指并发查询同一条数据，缓存雪崩是不同数据都过期了，大面积数据都查询不到，从而查询数据库。
1、设置热数据永不过期；
2、使用 避免大量请求同时查询DB；
3、做好熔断、降级，防止系统崩溃。
