java面试题--Redis

一、说一下redis的持久化机制原理？

1. RDB文件: redis database。存储的是某个时间点的数据库内容的快照，是结果。
   1. redis默认的持久化策略。
   2. 落盘策略：使用SAVE或者BGSAVE命令。(1)SAVE: 有主线程执行，会阻塞客户端。（2）BGSAVE：会fork出一个子进程，不会出现阻塞问题。子进程使用写时拷贝的策略，子进程页表项指向与父进程页表项相同的物理内存页，所以不会占用大量的内存。 可以使用命令配置自动执行落盘的条件。例如：save 900 2  900秒之内至少有2次修改就执行BGSAVE。
   3. 恢复策略：自动加载。redis在启动时检测是否存在RDB文件，存在的话，就载入。在载入完成之前，服务对外不可用。
2. AOF文件：AppendOnlyFile。存储的执行成功过的命令、参数。是过程。
   1. 落盘策略：分为三个阶段。（1）命令传播：命令、参数传播到AOF程序。（2）缓存追加：协议文本追加到aof_buf末尾。（3）文件写入和保存：调用faof.c/flushAppendOnlyFile 函数。这个函数执行以下两个工作：1、WRITE：根据条件，将 aof_buf 中的缓存写入到 AOF 文件。2、SAVE：根据条件，调用 fsync 或 fdatasync 函数，将 AOF 文件保存到磁盘中。
   2. 三种保存模式：（1）AOF_FSYNC_NO:不保存。WRITE 都会被执行， 但 SAVE 会被略过。（2）AOF_FSYNC_EVERYSEC：每一秒钟保存一次（默认）。（3）AOF_FSYNC_ALWAYS：每执行一个命令保存一次。（不推荐）
   3. AOF重写：名称BGREWRITEAOF
      1. Redis可以在 AOF体积变得过大时，自动地在后台（Fork子进程）对 AOF进行重写。
      2. Redis 增加了一个 AOF 重写缓存， 这个缓存在 fork 出子进程之后开始启用，Redis 主进程在接到新的写命令之后， 除了会将这个写命令的协议内容追加到现有的 AOF 文件之外，还会追加到这个缓存中。

      3. 当子进程在执行 AOF 重写时， 主进程需要执行以下三个工作：

         1. 处理命令请求。
         2. 将写命令追加到现有的 AOF 文件中。
         3. 将写命令追加到 AOF 重写缓存中。

      4. 当子进程完成 AOF 重写之后， 它会向父进程发送一个完成信号， 父进程在接到完成信号之后， 会调用一个信号处理函数， 并完成以下工作：

         1. 将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。

         2. 对新的 AOF 文件进行改名，覆盖原有的 AOF 文件。

         3. Redis数据库里的+AOF重写过程中的命令------->新的AOF文件---->覆盖老的。

         4. 当步骤 1 执行完毕之后， 现有 AOF 文件、新 AOF 文件和数据库三者的状态就完全一致了。
            当步骤 2 执行完毕之后， 程序就完成了新旧两个 AOF 文件的交替。
            
            

   4. AOF恢复策略：

      1. 创建一个不带网络连接的伪客户端（fake client）：因为Redis的命令只能在客户端上下文中执行，而载入AOF文件时所使用的命令直接来源于AOF文件而不是网络连接，所以服 务器使用了一个没有网络连接的伪客户端来执行AOF文件保存的写命令，伪客户端执行命令 的效果和带网络连接的客户端执行命令的效果完全一样。

      2. 从AOF文件中分析并读取出一条写命令。

      3. 使用伪客户端执行被读出的写命令。

      4. 一直执行步骤2和步骤3，直到AOF文件中的所有写命令都被处理完毕为止。

      5. 

3. RDB和AOF混合
   1. 使用RDB头+AOF部分。如果AOF文件以REDIS开头，则先执行RDB的数据快照。再执行AOF命令。

二、说一下对redis缓存雪崩、穿透、击穿的理解？

1. （1）缓存穿透：大量请求根本不存在的key。（2）缓存击穿：redis中一个热点key过期。（3）缓存雪崩：redis中大量key集体过期。
2. 缓存穿透解决方案：
   1. 对空值进行缓存，但是过期时间很短。最长不超过5分钟。
   2. 使用布隆过滤器：将所有可能存在的数据哈希到一个足够大的BITMAP中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
   3. 网警。
3. 缓存击穿解决方案：
   1. 加锁：在未命中缓存时，通过加锁避免大量请求访问数据库(只有一个线程可以进行热点数据的重构)。
   2. 不允许过期：物理不过期，也就是不设置过期时间。而是逻辑上定时的在后台异步的更新数据。
   3. 采用二级缓存。L1缓存失效时间短，L2缓存失效时间长。请求优先从L1缓存获取数据，如果未命中，则加锁，保证只有一个线程从数据库中读取数据，并更新到L1和L2缓存中。其他线程依然到L2缓存中获取数据。
4. 缓存雪崩解决方案：
1. 用加锁或者队列的方式保证缓存的单线程（进程）写。
2. 将缓存失效时间分散开。比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机。
3. 事前：这种方案就是在发生雪崩前对缓存集群实现高可用。如果是使用redis，可以使用主从+哨兵、Redis Cluster来避免redis全盘崩溃的情况。
4. 事中：使用Hystrix进行限流和降级。比如设置允许一秒2000个请求通过该组件，那么过来5000个请求时，有3000个请求会走限流逻辑，然后去调用我们自己开发的降级组件，比如设置一些默认值，以此来保护最后的MySQL不会被大量请求打死。
5. 事后：开启redis持久化机制，尽快恢复缓存集群。

三、redis的集群模式？

1. 主从复制模式。
   1. 一主多从。
   2. 无法实现故障转移。  
2. 哨兵模式。
   1. 一主多从。
   2. 故障转移步骤：
      1. master主观下线；
      2. master客观下线；
      3. Sentinel集群选举出Leader；
      4. Leader指定一个新的master。
3. Jedis Cluster模式。
   1. 多主多从。