面试宝典进阶之redis缓存面试题
R1、【初级】Redis常用的数据类型有哪些？
（1）String（字符串）
（2）Hash（哈希）
（3）List（列表）
（4）Set（集合）
（5）zset(sorted set：有序集合)
它还有三种特殊的数据结构类型
- Geospatial
- Hyperloglog
- Bitmap
理解思路
- 说出5种类型
- 说出每种类型的应用场景，要跟项目的业务结合
R2、redis的持久化方式有几种，项目中怎么选择？
（1）RDB：全量备份，节省磁盘空间，恢复速度快。但是可能会丢失数据。
（2）AOF：日志增量备份，数据保存完整。但是整体的恢复效率低，占空间。
（3）如果数据比较敏感的情况下，建议两个都开启。如果只是做纯缓存，数据不敏感，可以都不开启
（4）默认开启的是RDB。
R3、如果想在redis里面存储一个Java对象，能存吗？
（1）可以存储，项目中使用的redisTemplate默认的是将Vule值序列化后存储到redis。
（2）也可以将Java对象转成json字符串存储到redis。
R4、RedisTemplate和StringRedisTemplate区别？
（1）StringRedisTemplate继承了RedisTemplate但是两者的数据不能共用，RedisTemplate存储的数据只能通过RedisTemplate获取。
（2）StringRedisTemplate和RedisTemplate最大的区别就是默认采用的序列化策略不同，StringRedisTemplate默认的是String序列化，RedisTemplate默认使用的是JDK的序列化方式。
（3）StringRedisTemplate存储效率比RedisTemplate高，同时存储占用空间小。但是不如RedisTemplate灵活方便。当操作的数据是复杂的Java对象而不想做任何数据类型转换的时候那么建议使用RedisTemplate
理解思路
- 序列化方式不一样
R5、如何保证redis中存放的都是热点数据？
（1）设置redis的最大存储空间，建议设置为服务器内存的3/4。
（2）设置redis的内存淘汰策略，设置为volatile-lru或allkeys-lru。
（3）到达redis的最大值触发内存淘汰机制:
- volatile-lru:从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。
- allkeys-lru:从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰）
R6、什么是缓存击穿？
是针对缓存中没有但数据库有的数据。场景是，当一个热Key失效后，假如瞬间突然涌入大量的请求，来请求同一个Key，这些请求不会命中Redis，都会请求到DB，导致数据库压力过大，甚至扛不住，挂掉。
理解思路
- 某个热KEY
- 突然过期
- 数据库宕机
- 解决方式：设置永不过期
R7、什么是Redis的缓存雪崩？
（1）是指大量的热Key同时失效，对这些Key的请求就会瞬间打到DB上，同样会导致数据库压力过大甚至挂掉。
（2）解决方案：
- 设置KEY永不过期，但缺点是占用大量内存
- 设置KEY的过期时间为一个随机值，这样就能够防止大量的热KEY同时过期
理解思路
- 大量的
- 热KEY
- 短时间内过期
- 数据库宕机
- 解决方案：设置过期时间为随机数
R8、什么是缓存穿透？
（1）Redis缓存穿透指的是，在Redis缓存和数据库中都找不到相关的数据。也就是说这是个非法的查询，客户端发出了大量非法的查询 比如id是负的 ，导致每次这个查询都需要去Redis和数据库中查询。导致MySql直接爆炸！
（2）解决方案：
- 缓存空对象：如果他的查询数据是合法的，但是确实Redis和MySql中都没有，那么我们就在Redis中储存一个空对象，这样下次客户端继续查询的时候就能在Redis中返回了。但是，如果客户端一直发送这种恶意查询，就会导致Redis中有很多这种空对象，浪费很多空间
- 布隆过滤器：当我们想新增一个元素时（例如新增python），布隆过滤器就会使用hash函数计算出几个索引值，然后将二进制数组中对应的位置修改为1。
理解思路
- 大量的不存在的KEY
- 这些访问可能是恶意的
- 数据库宕机
- 解决：缓存前面布置布隆过滤器
R9、缓存击穿、缓存穿透、缓存雪崩的解决方案是什么？
R10、Redis是单线程的为什么速度还那么快？
（1）完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。
（2）数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
（3）采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
（4）使用多路I/O复用模型，非阻塞IO；所以可以一次性接收多个客户端请求，然后放到队列中；
理解思路
- 存储设备：内存
- 单线程：没有锁
- 数据结构专门设计
- 多路I/O复用
R11、Redis 是单进程单线程的吗？
（1）Redis 在设计上采用将网络数据读写和协议解析通过多线程的方式来处理，对于命令执行来说，仍然使用单线程操作。
（2）从Redis6 版本开始，已经引入了多线程。
理解思路
- 数据操作一直都是单线程的
- 在6.0以后，在网络数据传输、数据解析等使用了多线程，但是数据操作仍是单线程的
R12、Redis 的Key过期，他是怎么删除的？
（1）定时删除：在设置某个 key 的过期时间同时，我们创建一个定时器，让定时器在该过期时间到来时，立即执行对其进行删除的操作。
（2）惰性删除：设置该 key 过期时间后，我们不去管它，当需要该 key 时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该 key。
（3）定期删除：每隔一段时间，我们就对一些 key 进行检查，删除里面过期的 key。
R13、如何设置 Redis 的最大内存？
在配置文件 redis.conf 中，可以通过参数 maxmemory 来设定最大内存：
# In short... if you have slaves attached it is suggested that you set a lower
# limit for maxmemory so that there is some free RAM on the system for slave
# output buffers (but this is not needed if the policy is 'noeviction').
#
maxmemory
# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#
# volatile-lru -> remove the key with an expire set using an LRU algorithm
# allkeys-lru -> remove any key according to the LRU algorithm
# volatile-random -> remove a random key with an expire set
# allkeys-random -> remove a random key, any key
# volatile-ttl -> remove the key with the nearest expire time (minor TTL)
# noeviction -> don't expire at all, just return an error on write operations
理解思路
- 修改配置文件
R14、Redis 内存淘汰策略有哪些？
当使用的内存大于 maxmemory 时，就会触发 Redis 主动淘汰内存方式：
（1）volatile-lru：利用 LRU 算法移除设置过过期时间的 key (LRU：最近使用 Least Recently Used )；
（2）allkeys-lru：利用 LRU 算法移除任何key （和上一个相比，删除的 key 包括设置过期时间和不设置过期时间的），通常使用该方式；
（3）volatile-random：移除设置过过期时间的随机key ；
（4）allkeys-random：无差别的随机移除；
（5）volatile-ttl：移除即将过期的 key (minor TTL)；
（6）noeviction：不移除任何 key，只是返回一个写错误 ，默认选项，一般不会选用。
在 redis.conf 配置文件中，可以设置 maxmemory-policy 来设置内存淘汰方式：
# Note: with any of the above policies, Redis will return an error on write
# operations, when there are no suitable keys for eviction.
#
# At the date of writing these commands are: set setnx setex append
# incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
# sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
# zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
# getset mset msetnx exec sort
#
# The default is:
#
maxmemory-policy noeviction
理解思路
- 不要背英文
- 说淘汰方式
R15、Redis定期删除策略是定时删除所有过期的KEY吗？
Redis 的定期删除策略并不是一次运行就检查所有的库、所有的键，而是随机检查一定数量的键。
定期删除函数的运行频率，在 Redis2.6 版本中，规定每秒运行 10 次，大概 100ms 运行一次。在 Redis2.8 版本后，可以通过修改配置文件 redis.conf 的 hz 选项来调整这个次数：
# The range is tetween 1 and 500, however a value over 100 is usually not
# a good idea. Most users should use the default of 10 and raise this up to
# 100 only in environments where very low latency is requiried.
hz 10
才这个参数的上面注释可以看出，建议不要将这个值设置超过100，一般使用默认的10，只有当在需要非常低延迟的场景才设置为100。
R16、Redis的主从全量同步流程能说说吗？
（1）slave节点请求增量同步
（2）master节点判断replid，发现不一致，拒绝增量同步，使用全量同步
（3）master将完整数据生成RDB,发送RDB到slave
（4）slave清空本地数据，加载RDB文件
（5）master将RDB期间产生的命令记录在repl_baklog,并持续性的将repl_baklog发送到slave
（6）slave接收到这些命令，保持与master数据同步。
理解思路
- 谁先连谁
- 连接时，带什么东西
- 主收到id后，发送什么
R17、Redis的主从增量同步流程能说说吗？
（1）slave节点请求增量同步
（2）master节点判断replid，如果一致返回continue
（3）从repl_baklog中获取增量数据
（4）发送offset后面的命令
repl_baklog的容量是有上线的，写满后会覆盖最早的数据。如果slave断开的时间太久，导致尚未备份的数据被覆盖(offset会标记repl_baklog中备份的数据)，就无法做增量同步，只能去做全量同步。
R18、能说说你对布隆过滤器的理解吗？
（1）布隆过滤器（英语：Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。
（2）布隆过滤器的结构
R19、如果Redis服务崩溃了怎么办？
（1）给Redis设置持久化，这样服务器重启能够快速恢复到工作状态。
（2）搭建Redis集群实现高可用。
R20、你知道怎么实现Redis的高可用吗？
我们在项目中使用Redis，肯定不会是单点部署Redis服务的。因为，单点部署一旦宕机，就不可用了。为了实现高可用，通常的做法是，将数据库复制多个副本以部署在不同的服务器上，其中一台挂了也可以继续提供服务。
Redis 实现高可用有三种部署模式：
- 主从模式
- 哨兵模式
- 集群模式。
R21、说说你对Redis哨兵模式的理解？
主从模式中，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址。显然，多数业务场景都不能接受这种故障处理方式。Redis从2.8开始正式提供了Redis Sentinel（哨兵）架构来解决这个问题。
哨兵模式，由一个或多个Sentinel实例组成的Sentinel系统，它可以监视所有的Redis主节点和从节点，并在被监视的主节点进入下线状态时，自动将下线主服务器属下的某个从节点升级为新的主节点。但是呢，一个哨兵进程对Redis节点进行监控，就可能会出现问题（单点问题），因此，可以使用多个哨兵来进行监控Redis节点，并且各个哨兵之间还会进行监控。
理解思路
- 哨兵是一个独立的进程
- 每个哨兵监控一个服务器
- 哨兵实现消息通知和执行选举
R22、Redis哨兵模式的作用是什么？
简单来说，哨兵模式就三个作用：
（1）发送命令，等待Redis服务器（包括主服务器和从服务器）返回监控其运行状态；
（2）哨兵监测到主节点宕机，会自动将从节点切换成主节点，然后通过发布订阅模式通知其他的从节点，修改配置文件，让它们切换主机；
（3）哨兵之间还会相互监控，从而达到高可用。
R23、Redis哨兵模式故障切换的过程是怎样的呢？
（1）每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他Sentinel实例发送一个 PING命令。
（2）如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel标记为主观下线。
（3）如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
（4）当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线。
（5）在一般情况下， 每个 Sentinel 会以每10秒一次的频率向它已知的所有Master，Slave发送 INFO 命令。
（6）当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次
（7）若没有足够数量的 Sentinel同意Master已经下线， Master的客观下线状态就会被移除；若Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。
R24、Redis的Cluster集群模式解决了什么问题？
哨兵模式基于主从模式，实现读写分离，它还可以自动切换，系统可用性更高。但是它每个节点存储的数据是一样的，浪费内存，并且不好在线扩容。因此，Cluster集群应运而生，它在Redis3.0加入的，实现了Redis的分布式存储。对数据进行分片，也就是说每台Redis节点上存储不同的内容，来解决在线扩容的问题。并且，它也提供复制和故障转移的功能。
理解思路
- 高可用
- 提高性能
- 实现扩容
R25、Redis的Cluster集群节点之间是如何通讯的？
一个Redis集群由多个节点组成，各个节点之间是通过Gossip协议！
Redis Cluster集群通过Gossip协议进行通信，节点之前不断交换信息，交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot信息等等。常用的Gossip消息分为4种，分别是：ping、pong、meet、fail。
- meet消息：通知新节点加入。消息发送者通知接收者加入到当前集群，meet消息通信正常完成后，接收节点会加入到集群中并进行周期性的ping、pong消息交换。
- ping消息：集群内交换最频繁的消息，集群内每个节点每秒向多个其他节点发送ping消息，用于检测节点是否在线和交换彼此状态信息。
- pong消息：当接收到ping、meet消息时，作为响应消息回复给发送方确认消息正常通信。pong消息内部封装了自身状态数据。节点也可以向集群内广播自身的pong消息来通知整个集群对自身状态进行更新。
- fail消息：当节点判定集群内另一个节点下线时，会向集群内广播一个fail消息，其他节点接收到fail消息之后把对应节点更新为下线状态。
特别的，每个节点是通过集群总线(cluster bus) 与其他的节点进行通信的。通讯时，使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是 16379。nodes 之间的通信采用特殊的二进制协议。
R26、能说说Redis分布式集群是如何存储数据的吗？
Hash Slot插槽算法
既然是分布式存储，Cluster集群使用的分布式算法是一致性Hash嘛？并不是，而是Hash Slot插槽算法。
插槽算法把整个数据库被分为16384个slot（槽），每个进入Redis的键值对，根据key进行散列，分配到这16384插槽中的一个。使用的哈希映射也比较简单，用CRC16算法计算出一个16 位的值，再对16384取模。数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点都可以处理这16384个槽。
集群中的每个节点负责一部分的hash槽，比如当前集群有A、B、C个节点，每个节点上的哈希槽数 =16384/3，那么就有：
- 节点A负责0~5460号哈希槽
- 节点B负责5461~10922号哈希槽
- 节点C负责10923~16383号哈希槽
R27、如何保证mysql和redis的数据的一致性？
这是一个redis双写一致性的问题，我们的策略是**先删缓存，再写数据库，数据更新完成后，再删缓存**。