㈠ 该怎么解决 Redis 缓存穿透和缓存雪崩问题
缓存雪崩： 由于缓存层承载着大量请求，有效地 保护了存储层，但是如果缓存层由于某些原因不能提供服务，比如 Redis 节点挂掉了，热点 key 全部失效了，在这些情况下，所有的请求都会直接请求到数据库，可能会造成数据库宕机的情况。
预防和解决缓存雪崩问题，可以从以下三个方面进行着手：
1、使用 Redis 高可用架构：使用 Redis 集群来保证 Redis 服务不会挂掉
2、缓存时间不一致： 给缓存的失效时间，加上一个随机值，避免集体失效
3、限流降级策略：有一定的备案，比如个性推荐服务不可用了，换成热点数据推荐服务
缓存穿透： 缓存穿透是指查询一个根本不存在的数据，这样的数据肯定不在缓存中，这会导致请求全部落到数据库上，有可能出现数据库宕机的情况。
预防和解决缓存穿透问题，可以考虑以下两种方法：
1、缓存空对象： 将空值缓存起来，但是这样就有一个问题，大量无效的空值将占用空间，非常浪费。
2、布隆过滤器拦截： 将所有可能的查询key 先映射到布隆过滤器中，查询时先判断key是否存在布隆过滤器中，存在才继续向下执行，如果不存在，则直接返回。布隆过滤器有一定的误判，所以需要你的业务允许一定的容错性。
㈡ redis 宕机数据怎么办
用redis保存的*.rdb文件恢复即喊孝滚可。
另外redis还有AOF功慎槐能，启动时可以自动恢复到前一条查询。郑余
㈢ 每天一个知识点：宕机情况下，Redis 如何实现快速恢复
上一篇文章，我们讲到了宕机情况下，Redis 如何进行数据备份，那么，数据备份之后如何快速恢复呢？我的建议是使用内存快照（Redis Database）。
AOF 方法进行故障恢复的时候，需要逐一把操作日志都执行一遍。如果操作日志非常多，Redis 就会恢核没复得很缓慢，影响到正常使用。RDB 既可以保证可靠性，还能在宕机时实现快速恢复。
Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中，这就类似于给 100 个人拍合影，把每一个人都拍进照片里。这样做的好处是，一次性记录了所有数据，一个都不少。
Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave。
bgsave 可以避免阻塞，但避免阻塞和正常处理写操作并不是一回事。此时，主线程的确没有阻塞，可以正常接收请求，但是，为了保证快照完整性，它只能处理读操作，因为不能修改正在执行快照的数据。为了快照而暂停写操作，肯定是不能接受的。所以这个时候，Redis 就会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线链竖程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C），那么，这块数据就会被复制一份，生成该数据的副本（键值对 C’）。然后，主线程在这个数据副本上进行修改。同时，bgsave 子进程可以继续把原来的数据（键值对 C）写入 RDB 文件。
Redis 4.0 中提出了一个棚氏大混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。
关于 AOF 和 RDB 的选择问题，有三点建议：
㈣ “故障演练” Redis Cluster集群，当master宕机，主从切换
性能不够，缓存来凑
一个高并发系统肯定少不了缓存的身影，手型皮为了保证缓存服务的高可用，我们通常采用 Redis Cluster 集群模式。
描述：
集群部署采用了 3主3从 拓扑结构， 数据读写 访问master节点， slave节点负责备份。
随便登录一台 redis 节点，都可以看到集群的slot的槽位分步区间，以及对应的主从节点映射关系。
人为模拟，master-1 机器意外宕机
此时，Redis Cluster 集群能自动感知，并自动完成主备切换，对应的slave会被选举为新的master节点
看下 redis cluster 集群最新的主从关系
看似也没什么问题，一切正常
此时 Spring Boot 应用依然在线服务，当我们再尝试操作缓存时，会报错
问题边界还是非常清晰的。
Redis Cluster 集群已经完成了切换。
但是 Spring Boot 客户端 没有动态感知到 Redis Cluster 的最新集群信息毕差
原因分析：
SpringBoot 2.X 版本， Redis默认的连接池采用 Lettuce
当Redis 集群节点发生变化后，Letture默认是不会刷新节点拓扑
解决方案：
将 Letture 二方包仲裁掉
然后，引入 Jedis 相关二方包
编译代码租衫，并重新启动 SpringBoot 微服务，万事俱备，只欠再次验证
重新模拟将 127.0.0.1：8001 master 节点宕机，看看系统的日志
从打印的日志来看，客户端已经感知到了 主备切换 ，并与最新的主节点 127.0.0.1:8004 初始化了 24 个连接。
然后，回归业务功能， 读写缓存 数据也都是操作最新的主节点。
还有一种方案： 刷新节点拓扑视图
Lettuce 官方描述：
解决方案：
编写代码
㈤ docker部署,集成redis mysql,经常宕机怎么解决
docker 自带重启策略，restart有三个参数：no,on-failure,always
一般选择on-failure，也就是非正常宕机都或谨孝重启，手动停止不重启。
1.no为默认值，表示容器退出时，docker不自动重启容器
2.on-failure表示，若容器的退出状态非0，则docker自动重启容器,还可以晌喊指定重衫稿启次数，若超过指定次数未能启动容器则放弃：
3.always表示，只要容器退出，则docker将自动重启容器
㈥ django redis-cache服务重启后，缓存还在吗
还在，这个存储在redis里面，redis本身带持久化机制，正常的服务器重启对这个没有影响，除非你的redis 碰到突然crash这类的问题，可能会影响短时间内的数据正常。
㈦ redis 如何重启 linux下请输入命令不要用kill 的方式
1、如果是用apt-get或者yum install安装的redis，可以直接通过下面的命令停止/启动/重启redis：/etc/init.d/redis-server stop/etc/init.d/redis-server start/etc/init.d/redis-server restart
2、如果是通过源码安装的redis，则可以通过redis的客户端程序redis-cli的shutdown命令来重启redis。
㈧ Redis内存满了怎么办
长期把Redis做缓存用，总有一天Redis内存会满的，怎么处理呢？
在Redis的配置文件 redis.conf 文件中，配置 maxmemory 的大小参数如下所示：
倘若实际的存储中超出了Redis的配置参数的大小时，Redis中有 淘汰策略 ，把 需要淘汰的key给淘汰掉，整理出干净的一块内存给新的key值使用 。
Redis提供了 6种的淘汰策略 ，其中默认的是 noeviction ，这6中淘汰策略如下：
LRU(Least Recently Used) 即表示最近最少使用，也就是在最近的时间内最少被访问的key，算法根据数据的历史访问记录来进行淘汰数据。
它的核心的思想就是： 假如一个key值在最近很少被使用到，那么在将来也很少会被访问 。
实际上Redis实现的LRU并不是真正的LRU算法，也就是名义上我们使用LRU算法淘汰键，但是实际上被淘汰的键并不一定是真正的最久没用的。
Redis使用的是近似的LRU算法， 通过随机采集法淘汰key，每次都会随机选出5个key，然后淘汰里面最近最少使用的key 。
这里的5个key只是默认的个数，具体的个数也可以在配置文件中进行配置，在配置文件中的配置如下图所示：
当近似LRU算法取值越大谨手激的时候就会越接近真实的LRU算法，可以这样理解，因为 取值越大那么获取的数据就越全，淘汰中的数据的就越接近最近最少使用的数据 。
那么为了实现根据时间实现LRU算法，Redis必须为每个key中额外的增加一个内薯猜存空间用于存储每个key的时间，大小是3字节。
在Redis 3.0中对近似的LRU算法做了一些优化，Redis中会维护大小是 16 的一个候选池的内存。
当第一次随机选取的采样数据，数据都会被放进候选池中，并且候选池中的数据会根据时间进行排序。
当第二次以后选取的数据，只有 小于候选池内的最小时间 的才会被放进候选池中。
当某一时刻候选池的数据满了，那么时间最大的key就会被挤出候选池。当执行淘汰时，直接从候选池中选取最近访问时间最小的key进行淘汰。
这样做的目的就是选取出最近似符合最近最少被访问的key值，能够正确的淘汰key值，因为随机选取的样本中的最小时间可能不是真正意义上的最小时间。
但是LRU算法有一个弊端：就是假如一个key值在以前都没有被访问到，然而最近一次被访问到了，那么就会认为它是热点数据，不会被淘汰。
然而有些数据以前经常被访问到，只是最近的时间内没有被访问到，这样就导致这些数据很可能被淘汰掉，这样一来就会出现误判而淘汰热点数据。
于是在Redis 4.0的时候除了LRU算法，新加了一种LFU算法， 那么什么是LFU算法算法呢？
LFU(Least Frequently Used) 即表示最近频繁被使用，也就是最近的时间段内，频繁被访问的key，它以最近的时间段的被访问次祥袜数的频率作为一种判断标准。
它的核心思想就是：根据key最近被访问的频率进行淘汰，比较少被访问的key优先淘汰，反之则优先保留。
LFU算法反映了一个key的热度情况，不会因为LRU算法的偶尔一次被访问被认为是热点数据。
在LFU算法中支持 volatile-lfu 策略和 allkeys-lfu 策略。
在Redis种有三种删除的操作此策略，分别是：
在Redis中持久化的方式有两种 RDB 和 AOF
在RDB中是以快照的形式获取内存中某一时间点的数据副本，在创建RDB文件的时候可以通过 save 和 bgsave 命令执行创建RDB文件。
这两个命令都不会把过期的key保存到RDB文件中 ，这样也能达到删除过期key的效果。
当在启动Redis载入RDB文件的时候， Master 不会把过期的key载入，而 Slave 会把过期的key载入。
在AOF模式下，Redis提供了Rewite的优化措施，执行的命令分别是 REWRITEAOF 和 BGREWRITEAOF ， 这两个命令都不会把过期的key写入到AOF文件中，也能删除过期key 。
RDB 是一种快照存储持久化方式，具体就是将 Redis 某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为 mp.rdb ，而在 Redis 服务器启动时，会重新加载 mp.rdb 文件的数据到内存当中恢复数据。
开启RBD持久化方式
开启 RDB 持久化方式很简单，客户端可以通过向 Redis 服务器发送 save 或 bgsave 命令让服务器生成 rdb 文件，或者通过服务器配置文件指定触发 RDB 条件。
save 命令是一个同步操作。
当客户端向服务器发送 save 命令请求进行持久化时，服务器会阻塞 save 命令之后的其他客户端的请求，直到数据同步完成。
与 save 命令不同， bgsave 命令是一个异步操作。
当客户端发服务发出 bgsave 命令时， Redis 服务器主进程会 forks 一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出。
所以，与 save 命令相比， Redis 服务器在处理 bgsave 采用子线程进行IO写入，而主进程仍然可以接收其他请求，但 forks 子进程是同步的，所以 forks 子进程时，一样不能接收其他请求，这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。
除了通过客户端发送命令外，还有一种方式，就是在 Redis 配置文件中的 save 指定到达触发RDB持久化的条件，比如【多少秒内至少达到多少写操作】就开启 RDB 数据同步。
例如我们可以在配置文件redis.conf指定如下的选项：
之后在启动服务器时加载配置文件。
这种通过服务器配置文件触发RDB的方式，与bgsave命令类似，达到触发条件时，会forks一个子进程进行数据同步，不过最好不要通过这方式来触发RDB持久化，因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能，时间设置太长则会造成数据丢失。
介绍了三种让服务器生成rdb文件的方式，无论是由主进程生成还是子进程来生成，其过程如下：
Redis 的另外一个持久化方式： AOF(Append-only file) 。
与 RDB 存储某个时刻的快照不同， AOF 持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以 Redis 协议追加保存到以后缀为 aof 文件末尾，在Redis服务器重启时，会加载并运行 aof 文件的命令，以达到恢复数据的目的。
Redis默认不开启AOF持久化方式，我们可以在配置文件中开启并进行更加详细的配置，如下面的redis.conf文件：
在上面的配置文件中，我们可以通过 appendfsync 选项指定写入策略,有三个选项
客户端的每一个写操作都保存到 aof 文件当，这种策略很安全，但是每个写请注都有IO操作，所以也很慢。
appendfsync 的默认写入策略，每秒写入一次 aof 文件，因此，最多可能会丢失1s的数据。
Redis 服务器不负责写入 aof ，而是交由操作系统来处理什么时候写入 aof 文件。更快，但也是最不安全的选择，不推荐使用。
AOF将客户端的每一个写操作都追加到 aof 文件末尾，比如对一个key多次执行incr命令，这时候， aof 保存每一次命令到aof文件中，aof文件会变得非常大。
aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：
通过在redis.conf配置文件中的选项no-appendfsync-on-rewrite可以设置是否开启重写，这种方式会在每次fsync时都重写，影响服务器性能，因此默认值为no，不推荐使用。
客户端向服务器发送bgrewriteaof命令，也可以让服务器进行AOF重写。
AOF重写方式也是异步操作，即如果要写入aof文件，则Redis主进程会forks一个子进程来处理，如下所示：
在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。
AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
我们可以从几个方面对比一下RDB与AOF,在应用时，要根本自己的实际需求，选择RDB或者AOF，其实，如果想要数据足够安全，可以两种方式都开启，但两种持久化方式同时进行IO操作，会严重影响服务器性能，因此有时候不得不做出选择。
当RDB与AOF两种方式都开启时，Redis会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。
㈨ Redis主从结构，主库宕机挂了，怎么办
连上从库，做save操作。将会在从掘仿兆库的data目录保存一份判租从库最新的mp.rdb文件。将这份大颂mp.rdb文件拷贝到主库的data目录下。再重启主库。
㈩ Redis主从结构，主库宕机挂了，怎么办
因为主库没有配置持久化，所以主库的data目录只有从库连接主库请求resync的时候做快照留下来的mp.rdb文件。
如果重启主库，主库会按粗备照data目录下的mp.rdb来恢复数据。
因此，如果从库是从最开始就配置好了的而且没有发生过再次请求resync，那么此时的mp.rdb将是稿野空的。主库按照空的mp.rdb恢复数据，自然数据键凳喊全无，从库发现主库能够连接上时会自动请求resync,从库也将拷贝一份空白的数据。