Redis面试题总结（超详细）
Redis是什么
Redis是基于内存运行的高性能 K-V 数据库
Redis存储位置
内存中，所以效率高
Redis的五种数据结构
- String：Redis最基本的数据类型，一个键对应一个值，一个键值最大存储512MB
- set：是String字符串类型的无序集合，也不可重复
- zset：是String类型的有序集合，也不可重复。有序集合中的每个元素都需要指定一个分数，根据分数对元素进行升序排序
- hash：hash是一个键值对的集合，是一个String类型的field和value的映射表，适合用于存储对象
- list：是redis的简单的字符串列表，按插入顺序排序
Redis应用场景（可以用来做什么）
可用于缓存，事件发布或订阅，高速队列等场景 众多语言都支持Redis，因为Redis交换数据快，在服务器中常用来存储一些需要频繁调取的数据，节省内存开销，也极大的提升了速度。 将一些热点数据存储到Redis中，要用的时候，直接从内存取，极大的提高了速度和节约了服务器的开销。
- 会话缓存（最常用）
- 消息队列（支付）
- 活动排行榜或计数
- 发布，订阅消息（消息通知）
- 商品列表，评论列表
为什么使用Redis
- 完全基于内存，数据存在内存中，绝大部分请求是纯粹的内存操作，非常快速，跟传统的磁盘文件数据存储相比，避免了通过磁盘IO读取到内存这部分的开销。
- 数据结构简单，对数据操作也简单。Redis中的数据结构是专门进行设计的，每种数据结构都有一种或多种数据结构来支持。Redis正是依赖这些灵活的数据结构，来提升读取和写入的性能。
- 采用单线程，省去了很多上下文切换的时间以及CPU消耗，不存在竞争条件，不用去考虑各种锁的问题，不存在加锁释放锁操作，也不会出现死锁而导致的性能消耗。
- 使用基于IO多路复用机制的线程模型，可以处理并发的链接。
雪崩
雪崩概念
如果缓在某一个时刻出现大规模的key失效，那么就会导致大量的请求打在了数据库上面，导致数据库压力巨大，如果在高并发的情况下，可能瞬间就会导致数据库宕机。这时候如果运维马上又重启数据库，马上又会有新的流量把数据库打死。这就是缓存雪崩
为什么会发生雪崩
- 第一种是Redis宕机
- 第二种可能就是采用了相同的过期时间
雪崩解决方案
- 事前
- 均匀过期：设置不同的过期时间，让缓存失效的时间尽量均匀，避免相同的过期时间导致缓存雪崩，造成大量数据库的访问。
- 分级缓存：第一级缓存失效的基础上，访问二级缓存，每一级缓存的失效时间都不同。
- 热点数据缓存永远不过期
- 保证Redis缓存的高可用，防止Redis宕机导致缓存雪崩的问题。可以使用 主从+ 哨兵，Redis集群来避免 Redis 全盘崩溃的情况
- 事中
- 互斥锁：在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降
- 使用熔断机制，限流降级。当流量达到一定的阈值，直接返回“系统拥挤”之类的提示，防止过多的请求打在数据库上将数据库击垮，至少能保证一部分用户是可以正常使用，其他用户多刷新几次也能得到结果。
- 事后：
- 开启Redis持久化机制，尽快恢复缓存数据，一旦重启，就能从磁盘上自动加载数据恢复内存中的数据。
永不过期实际包含两层意思：
- 物理不过期，针对热点key不设置过期时间
- 逻辑过期，把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建
击穿
击穿概念
缓存击穿跟缓存雪崩有点类似，缓存雪崩是大规模的key失效，而缓存击穿是某个热点的key失效，大并发集中对其进行请求，就会造成大量请求读缓存没读到数据，从而导致高并发访问数据库，引起数据库压力剧增。这种现象就叫做缓存击穿
为什么会发生击穿
关键在于某个热点的key失效了，导致大并发集中打在数据库上。
解决方向
- 第一是否可以考虑热点key不设置过期时间
- 第二是否可以考虑降低打在数据库上的请求数量
解决方案
- 在缓存失效后，通过互斥锁或者队列来控制读数据写缓存的线程数量，比如某个key只允许一个线程查询数据和写缓存，其他线程等待。这种方式会阻塞其他的线程，此时系统的吞吐量会下降
- 热点数据缓存永远不过期。
穿透
穿透概念
缓存穿透是指用户请求的数据在缓存中不存在即没有命中，同时在数据库中也不存在，导致用户每次请求该数据都要去数据库中查询一遍。如果有恶意攻击者不断请求系统中不存在的数据，会导致短时间大量请求落在数据库上，造成数据库压力过大，甚至导致数据库承受不住而宕机崩溃。
为什么会发生穿透
缓存穿透的关键在于在Redis中查不到key值，它和缓存击穿的根本区别在于传进来的key在Redis中是不存在的。假如有黑客传进大量的不存在的key，那么大量的请求打在数据库上是很致命的问题，所以在日常开发中要对参数做好校验，一些非法的参数，不可能存在的key就直接返回错误提示。
解决方案
- 将无效的key存放进Redis中： 当出现Redis查不到数据，数据库也查不到数据的情况，我们就把这个key保存到Redis中，设置value=“null”，并设置其过期时间极短，后面再出现查询这个key的请求的时候，直接返回null，就不需要再查询数据库了。但这种处理方式是有问题的，假如传进来的这个不存在的Key值每次都是随机的，那存进Redis也没有意义。
- 使用布隆过滤器： 如果布隆过滤器判定某个 key 不存在布隆过滤器中，那么就一定不存在，如果判定某个 key 存在，那么很大可能是存在(存在一定的误判率)。于是我们可以在缓存之前再加一个布隆过滤器，将数据库中的所有key都存储在布隆过滤器中，在查询Redis前先去布隆过滤器查询 key 是否存在，如果不存在就直接返回，不让其访问数据库，从而避免了对底层存储系统的查询压力。
如何选择解决方案
针对一些恶意攻击，攻击带过来的大量key是随机，那么我们采用第一种方案就会缓存大量不存在key的数据。那么这种方案就不合适了，我们可以先对使用布隆过滤器方案进行过滤掉这些key。所以，针对这种key异常多、请求重复率比较低的数据，优先使用第二种方案直接过滤掉。而对于空数据的key有限的，重复率比较高的，则可优先采用第一种方式进行缓存。
Redis集群
什么是Redis集群
Redis 3.0加入了Redis的集群模式，实现了数据的分布式存储，对数据进行分片，将不同的数据存储在不同的master节点上面，从而解决了海量数据的存储问题。
集群的搭建
- 启动节点：将节点以集群方式启动，此时节点是独立的。
- 节点握手：将独立的节点连成网络。
- 槽指派：将16384个槽位分配给主节点，以达到分片保存数据库键值对的效果。
- 主从复制：为从节点指定主节点。
为什么需要Redis集群
在讲Redis集群架构之前，我们先简单讲下Redis单实例的架构，从最开始的一主N从，到读写分离，再到Sentinel哨兵机制，单实例的Redis缓存足以应对大多数的使用场景，也能实现主从故障迁移 但是，在某些场景下，单实例存Redis缓存会存在的几个问题：
- 写并发： Redis单实例读写分离可以解决读操作的负载均衡，但对于写操作，仍然是全部落在了master节点上面，在海量数据高并发场景，一个节点写数据容易出现瓶颈，造成master节点的压力上升。
- 海量数据的存储压力： 单实例Redis本质上只有一台Master作为存储，如果面对海量数据的存储，一台Redis的服务器就应付不过来了，而且数据量太大意味着持久化成本高，严重时可能会阻塞服务器，造成服务请求成功率下降，降低服务的稳定性。
针对以上的问题，Redis集群提供了较为完善的方案，解决了存储能力受到单机限制，写操作无法负载均衡的问题。
Redis集群中节点的通信机制
gossip协议
Redis集群的数据分布算法
Redis集群采用的算法是哈希槽分区算法。Redis集群中有16384个哈希槽（槽的范围是 0 -16383，哈希槽），将不同的哈希槽分布在不同的Redis节点上面进行管理，也就是说每个Redis节点只负责一部分的哈希槽。在对数据进行操作的时候，集群会对使用CRC16算法对key进行计算并对16384取模（slot = CRC16(key)%16383），得到的结果就是 Key-Value 所放入的槽，通过这个值，去找到对应的槽所对应的Redis节点，然后直接到这个对应的节点上进行存取操作。
使用哈希槽的好处
使用哈希槽的好处就在于可以方便的添加或者移除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；哈希槽数据分区算法具有以下几种特点：
- 解耦数据和节点之间的关系，简化了扩容和收缩难度；
- 节点自身维护槽的映射关系，不需要客户端代理服务维护槽分区元数据
- 支持节点、槽、键之间的映射查询，用于数据路由，在线伸缩等场景
槽的迁移与指派命令
CLUSTER ADDSLOTS 0 1 2 3 4 … 5000
集群扩容
- 启动新节点
- 使用cluster meet命令将新节点加入到集群
- 迁移槽和数据：添加新节点后，需要将一些槽和数据从旧节点迁移到新节点
集群收缩
- 迁移槽。
- 忘记节点。通过命令 cluster forget {downNodeId} 通知其他的节点
哨兵机制
什么是哨兵模式
在主从模式下（主从模式就是把所有哨兵去掉），master节点负责写请求，然后异步同步给slave节点，从节点负责处理读请求。如果master宕机了，需要手动将从节点晋升为主节点，并且还要切换客户端的连接数据源。这就无法达到高可用，而通过哨兵模式就可以解决这一问题。
哨兵模式是Redis的高可用方式，哨兵节点是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。 哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点挂掉时，哨兵会第一时间感知到，并且在slave节点中重新选出来一个新的master，然后将新的master信息通知给client端，从而实现高可用。这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息
哨兵的主要工作任务
- 监控：哨兵会不断地检查你的Master和Slave是否运作正常。
- 提醒：当被监控的某个Redis节点出现问题时，哨兵可以通过 API 向管理员或者其他应用程序发送通知。
- 自动故障迁移：当一个Master不能正常工作时，哨兵会进行自动故障迁移操作，将失效Master的其中一个Slave升级为新的Master，并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用新Master代替失效Master
哨兵模式搭建
- 配置sentinel.conf文件，配件需要监听的主从的master节点
- 如果主从master设置了密码，还需要配置
- 修改心跳检测的主观下线时间
- 从服务器的个数配置
- 启动指定的哨兵配置文件启动哨兵
- 查看状态信息 配置完之后，进入./redis-cli，输入info命令，查看哨兵的状态信息
- Java客户端连接哨兵模式，只需要配置哨兵节点即可
哨兵模式的工作原理
- 心跳机制
- 判断master节点是否下线
- 基于Raft算法选举领头sentinel
- 故障转移
- 修改配置
持久化机制
什么是持久化机制
Redis是一个基于内存的数据库，所有的数据都存放在内存中，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制
Redis的持久化机制有两种，第一种是RDB快照，第二种是AOF日志
RDB快照
RDB快照就是把数据以快照的形式保存在磁盘上，是某个时间点的一次全量数据备份，以二进制序列化形式的文件存储，并且在存储上非常紧密。 RDB持久化是指在指定的时间间隔内将内存中的数据集以快照的方式写入磁盘，并保存到一个名为dump.rdb的二进制文件中，也是默认的持久化方式，它恢复时是将快照文件从磁盘直接读到内存里。
RDB来说持久化触发机制有三种：save、bgsave、自动化触发
RDB快照优势
- RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
- 对于大规模数据的恢复，且对于数据恢复的完整性不是非常敏感的场景，RDB的恢复速度要比AOF方式更加的高效。
- 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
RDB快照劣势
- fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。
- 当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。
- 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。
AOF日志
每次都使用RDB机制全量备份的方式是非常耗时间的，因此Redis还提供了另一种持久化机制AOF（append only file）。AOF日志是持续增量的备份，将Redis执行过的每个写操作以日志的形式记录下来(读操作不记录)，只许追加文件但不可以改写文件(appendonly.aof文件)。redis启动的时候会读取该文件进行数据恢复，根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF持久化触发机制
- 每修改同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。
- 每秒同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失。
- 不同步：appendfsync no 从不同步
AOF日志优势
- AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
- AOF只是追加写日志文件，对服务器性能影响较小，速度比RDB要快，消耗的内存较少
- AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
- AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。
AOF日志劣势
- 对于相同数据集的数据而言，aof文件要远大于rdb文件，恢复速度慢于rdb。
- 对于每秒一次同步的情况，aof运行效率要慢于rdb，不同步效率和rdb相同。
注：如果同时开启两种持久化方式，在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
Redis4.0的混合持久化
大量数据使用粗粒度（时间上）的rdb快照方式，性能高，恢复时间快。 增量数据使用细粒度（时间上）的AOF日志方式，尽量保证数据的不丢失。
RDB快照和AOF日志的区别
RDB快照是一次全量备份，AOF是连续的增量备份。 RDB快照是内存数据的二进制序列化形式，在存储上非常紧凑，而 AOF 日志记录的是内存数据修改的指令记录文本
RDB------>内存中数据集的快照，默认开启，恢复速度快，数据容易丢失 AOF------>操作日志，默认关闭，恢复速度慢，安全
Redis的分布式锁
什么是分布式锁
分布式锁，即分布式系统中的锁。在单体应用中我们通过锁解决的是控制共享资源访问的问题，而分布式锁，就是解决了分布式系统中控制共享资源访问的问题。与单体应用不同的是，分布式系统中竞争共享资源的最小粒度从线程升级成了进程
分布式锁应该具备哪些条件
- 在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行
- 高可用的获取锁与释放锁
- 高性能的获取锁与释放锁
- 具备可重入特性（可理解为重新进入，由多于一个任务并发使用，而不必担心数据错误）
- 具备锁失效机制，即自动解锁，防止死锁
- 具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败
分布式锁的实现方式
- 基于数据库实现分布式锁
- 基于Zookeeper实现分布式锁
- 基于reids实现分布式锁
mysql ----> 行锁 + 乐观锁。获取锁：select update ；执行业务；释放锁：本地事物提交。 Zookeeper -----> 公平锁。获取锁：创建节点（临时顺序）；执行业务 ；释放锁：关闭连接，临时顺序节点自动删除。 redis --------> 加锁 setnx orderlock A expire 设置过期时间； 释放锁：del orderlock。
Redis存储中文方式
正常情况下 ，取数据不会有问题，但是难免会有的时候由于编码格式不一样，而导致取不到数据，这个时候，就需要我们对存储的key做一个特殊的处理
使用基本编码
String base64encodedString = Base64.getEncoder().encodeToString(“我爱中国”.getBytes(“utf-8”));
解码
byte[] base64decodedBytes = Base64.getDecoder().decode(base64encodedString);
常见的分区算法
- hash算法：将key使用hash算法计算之后，按照节点数量来取余，即hash(key)%N。优点就是比较简单，但是扩容或者摘除节点时需要重新根据映射关系计算，会导致数据重新迁移。
- 一致性hash算法：为每一个节点分配一个token，构成一个哈希环；查找时先根据key计算hash值，然后顺时针找到第一个大于等于该哈希值的token节点。优点是在加入和删除节点时只影响相邻的两个节点，缺点是加减节点会造成部分数据无法命中，所以一般用于缓存，而且用于节点量大的情况下，扩容一般增加一倍节点保障数据负载均衡。