redis缓存的雪崩、击穿、穿透，淘汰策略，持久化

1、redis缓存的雪崩、击穿、穿透，在实际中如何处理？

雪崩：缓存不存在，数据库存在，高并发，大量的key

原因：大量数据同时过期，Redis宕机

解决方案：给缓存数据的过期时间上加上小的随机数，避免造成同时过期；互斥锁；服务降级；服务熔断；请求限流；Redis缓存主从集群

击穿：缓存不存在，数据库存在，高并发，少量的key

原因：经常访问的热点数据过期

解决方案：不给热点数据设置过期时间，一直保留

穿透：缓存不存在，数据库不存在，高并发，少量的key

原因：要访问的数据既不在缓存也不在数据库

解决方案：缓存空值或缺省值；请使用布隆过滤器快速判断（布隆过滤器只能判断数据一定不在数据库，但是不能判读数据一定在数据库）；请求入口前端对合法请求合法性进行判断

2、Redis的淘汰策略

Redis内存不足的缓存淘汰策略提供了8种。

• noeviction（默认）：不删除键，返回错误
• allkeys-lru：针对所有的key，使用lru算法进行淘汰
• volatile-lru：针对设置了过期时间的key，使用lru算法进行淘汰
• allkeys-random：针对所有的key，采用随机淘汰
• volatile-random：针对设置了过期时间的key，采用随机淘汰
• volatile-ttl：删除生存时间最近的一个键
• volatile-lfu：针对设置了过期时间的key，使用lfu算法进行淘汰
• allkeys-lfu：针对所有的key，使用lfu算法进行淘汰

主要是四种算法，针对不同的key，形成的策略

• lru：最近最少使用，淘汰最长时间没有使用的
• lfu：最不经常使用，淘汰一段时间内，使用次数最少的
• random：随机淘汰
• ttl：快要到过期的先淘汰

回收进程是如何工作的：

• 一个客户端运行了新命令，添加了新的数据
• Redis检查内存的使用情况，如果大于maxmemory的限制。则根据事先设定好的策略进行回收
• 一个新的命令被执行，等等
• 所以我们不断地穿越内存限制的边界，通过不断达到边界然后不断地回收边界以下。

如果一个命令的结果导致大量内存被使用（例如很大的集合的交集保存到了一个新的键），不用多久内存限制就会被这个内存使用量超越

3、Redis持久化机制：RDB和AOF

Redis持久化

Redis提供了不同级别的持久化方式：

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据。AOF命令以Redis协议追加保存每次写的操作到文件的末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大

  如果你希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式

  你也可以同时开启两种持久化方式，在这种情况下，当Redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF保存的数据集要比RDB文件保存的数据集要完整

  最重要的事情是了解RDB和AOF持久化方式的不同

RDB的优点：

• RDB是一个非常紧凑的文件，他保存了某个时间点的数据集，非常适用于数据集的备份，比如你可以在每个小时保存一下过去24小时内的数据，同时每天保存过去30 天的数据，这样即使出现问题，你也可以根据需求恢复到不同版本的数据集
• RDB是一个紧凑的单一文件，很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部有子进程来做，父进程不需要再做其他的IO操作，所以RDB持久化的方式可以最大化Redis性能
• 与AOF相比，在恢复大的数据集时候，RDB方式会更快一些

RDB的缺点：

• 如果你希望在Redis意外停止工作的情况下丢失的数据最小的话，那么RDB不适合，虽然你可以配置不同的save时间点（例如每隔5分钟并且对数据集有100个写的操作），是Redis要完整的保存整个数据集是一个比较繁重的工作。你通常会每隔5分钟或者更久做完一次完整的保存，万一在Redis意外宕机，你可能会丢失几分钟的数据
• RDB需要fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程非常耗时，可能会导致Redis在一些毫秒级内不能响应客户端的请求，如果数据集巨大并且CPU性能不是很好的情况下，这种情况会持续1秒，AOF也需要fork，但是你可以调节重新日志文件的频率来提高数据集的耐久度

AOF的优点：

• 使用AOF会让你的Redis更耐久，AOF的三种同步策略：同步时机由内核决定，每一秒同步一次，每执行一个命令同步一次
• Redis可以在AOF文件体积变得过大时，自动地在后台对AOF重写，一旦新的AOF文件创建完毕，Redis就会从旧的AOF文件切换到新的AOF文件，并且开始对新的文件进行追加操作
• AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂

AOF的缺点：

• 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积
• 根据所使用的的fsync策略，AOF的速度可能要慢于RDB

4、为什么Redis快？

1、采用高效的优化过的数据结构（C语言实现），在几种基础的数据结构上，redis 做了大量优化，性能极高；
2、完全基于内存操作；
3、单线程运行[1]，省去了上下文切换成本；
4、使用非阻塞的 IO 多路复用机制；
5、惰性删除机制；

redis6.0 之后其实已经改用多线程了，但并非是完全摒弃单线程，redis 依然使用单线程模型来处理客户端请求，只是使用多线程来处理数据的读写和协议解析。
这样做的目的是因为 redis 的性能瓶颈在于网络 IO 而非 CPU，使用多线程能提升 IO 读写的效率，从而整体提高 redis 的性能