Redis面试题
一、Redis缓存
1、缓存预热、缓存穿透、缓存雪崩、缓存击穿
-
缓存预热： 系统上线后，提前将相关数据加载到缓存中，避免用户先查库，然后再查缓存。
-
缓存穿透： 指缓存和数据库中都没有的数据，导致所有的请求都落在数据库上，造成数据库短时间内承受大量请求而崩掉。
解决方案：
1）缓存空对象：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。
2）布隆过滤器：是指在客户端和redis之间又加了一层布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储查询压力，但不一定是准确的，返回存在却不一定是存在。
Redisson实现的布隆过滤器：底层主要是先去初始化一个比较大的数组，里面存放的是二进制0或1，在一开始全是0，当存储一个key时，经过3次hash计算，模于数组长度找到数据的下标后把数组中原来的0改为1，这样就能通过三个数组的位置标明一个key的存在。
缺点：存在一定的误判率，一般可以设置这个误判率，5%以内一般都能接受。 -
缓存雪崩： 指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。
解决方案：
1）给不同key的TTL（过期时间）添加随机值，将失效时间分散开来。
2）缓存预热：指系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题 -
缓存击穿： 缓存击穿问题也叫热点key问题，就是被一个高并发访问并且缓存重建业务较复杂的key突然失效了，无数请求访问会在瞬间给数据库带来巨大的冲击。
解决方案：
1）互斥锁：用锁的方式只让一个线程来重建缓存数据，其他线程等待缓存构建。适用于强一致性，性能没那么高
2）逻辑过期：设置热点key永不过期，一个线程来获取互斥锁开启写入线程，其他线程获取互斥锁失败，则获取缓存中的旧数据。适用于不严格要求数据一致性。
2、redis作为缓存，MySQL的数据如何与缓存进行同步（保证双写一致性）
-
采用redisson实现的读写锁来保证强一致性：
在读的时候添加 共享锁，可以保证读读不互斥，读写互斥。更新数据时，使用 排他锁，读写、读读都互斥，这样就能保证在写数据的同时是不会让其他线程读数据的，避免了脏数据。需注意要将读方法和写方法上的锁使用同一把锁。
排他锁底层使用的是setnx，保证了同时只能有一个线程操作锁住的方法。
延迟双删： 如果是写操作，先把缓存中的数据删除，然后更新数据库，最后再延时删除缓存中的数据，其中这个延时多久不太好确定，在延时的过程中可能出现脏数据，并不能保证强一致性，所以没有采用它。 -
数据同步允许有一定的延迟：
采用阿里的canal组件实现数据同步，不需要更改业务代码，部署一个canal服务。canal服务把自己伪装成mysql的一个从节点，当mysql数据更新以后，canal会读取binlog数据，然后在通过canal的客户端获取到数据，更新缓存即可。
3、redis作为缓存，如何持久化数据？
- redis中提供了两种数据持久化的方式：RDB、AOF。
- RDB是一个快照文件，他是把redis内存存储的数据写到磁盘上，当redis实例宕机恢复数据的时候，方便从RDB的快照文件中恢复数据。
- AOF的含义是追加文件，当redis操作写命令的时候，都会存储这个文件中，当redis实例宕机恢复数据的时候，会从这个文件中再次执行一遍命令来恢复数据。
- 两种方式中，RDB恢复的速度比较快。因为是二进制文件，在保存的时候体积也比较小，所以恢复的比较快，但是它有可能会丢数据，通常项目中也会使用AOF来恢复数据，虽然AOF恢复数据比较慢，但是数据安全要高些，在AOF文件中可以设置刷盘策略，如可设置每秒批量写入一次命令。
4、redis的key过期后会立即删除吗？（redis的数据过期策略）
- Redis对数据设置数据的有效时间，数据过期以后，就需要将数据从内存中删除掉，可以按照不同的规则进行删除，这种删除规则就被称之为数据的过期删除策略。
5、假如缓存过多，内存有限，被占满了怎么办？（redis的数据淘汰策略）
- 当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。
- 在redis这提供了8种不同的策略，默认使用的是noeviction，不删除任何数据，内存不足直接报错。
- 数据库有1000万数据，Redis只能缓存20w数据，如何保证Redis中的数据都是热点数据？
使用allkeys-lru策略，挑选最近最少使用的数据淘汰，留下的都是经常访问的热的数据。 - Redis的内存用完了会发生什么，主要看数据淘汰策略是什么，如默认使用的是noeviction，会直接报错。
6、
二、Redis分布式锁
1、Redis分布式锁如何使用？（使用场景）
-
举例：
抢券功能：如果是单体项目，直接用synchronized(this)同步代码块就能解决并发问题。但如果是服务集群部署，将同一份代码部署在多台机器中，则不能再使用同步锁，此时则可以使用redis的分布式锁来解决。 -
分布式锁所要解决的问题的本质是：能够对分布在多台机器中的线程对共享资源的互斥访问。
-
Redis实现分布式锁主要利用redis的 setnx 命令。setnx是SET if not exists（如果不存在，则SET）的简写。
// 添加锁 NX是互斥，EX是设置超时时间
// 注意不能将该条命令分成两条命令实现，因其两条命令不能保证原子性
SET lock value NX EX 10
// 释放锁 删除
DEL key
2、Redis分布式锁如何合理的控制锁的有效时长？
-
在获取Redis分布式锁锁成功后执行业务，如果执行业务的时间超时过期 或 在执行业务的途中服务宕机了，此时Redis会自动释放锁，从而可能造成数据的不一致性。
-
解决方法：
1）根据业务执行时间预估，但一般都可能无法预期，所以不建议使用
2）给锁续期，再创建一个新的线程来监控业务执行了多久，如果监控到业务执行的时间比较长，就增加线程持有锁的时长，redisson实现的分布式锁已经实现了该功能。
3、Redisson实现的分布式锁执行流程（实现原理）
-
Redisson实现的分布式锁也是基于setnx 命令实现的，只是对其做了很多增强和优化。
-
一个线程获取到分布式锁之后，就可以操作redis数据库了，不同的是Redisson会另开一个线程，类似看门狗一样，用来监控这个持有锁的线程，一般是每隔（releaseTime过期时间 / 3)的时间给持有锁的线程做一次续期。假设过期时间为30秒，则每10秒的时间都会给持有锁的线程续期，每次续期时间都为30秒。
-
当业务完成以后，手动释放锁，同时需要通知这个监控线程锁已被删除了，则不需要再做监听了。
-
若线程一开始获取分布式锁失败了，并不会直接中断失败，而是运用了while循环来不断的尝试获取锁，设置了一定的循环次数去获取锁，如果超过了这个次数就直接失败了。（重试机制）
-
所有的加锁、释放锁、设置过期时间等操作都是基于lua脚本完成的。lua脚本的作用就是能保证基于redis实现的多行代码中的原子性。
public void redisLock() throws InterruptedException {
// 获取锁（重入锁），设置执行锁的名称
RLock lock = redissonClient.getLock("lock1");
// 尝试获取锁，参数分别是：分布式锁的最大等待时间 、 锁自动释放时间 、 时间单位
// 第二个参数可不填，如果传入了第二个参数，代表可自己能确定业务的执行时间，则不会再另起一个线程做监控。
// boolean isLock = lock.tryLock(10, 30, TimeUnit.SECONDS)
boolean isLock = lock.tryLock(10, TimeUnit.SECONDS);
// 判断是否获取成功
if（isLock) {
try {
System.out.println(""执行业务);
} finally {
// 释放锁
lock.unlock();
}
}
}
4、Redisson实现的分布式锁是否是可重入锁？（可重入锁）
-
redis实现的分布式锁是不可重入的，但Redisson实现的分布式锁是可重入的，与Java中的ReentranLock是一样的，都是判断是否是同一个线程来判断是否可重入，如果是同一个线程则可重入。
-
当业务比较复杂时，锁粒度比较细时 会用到重入锁的，可以避免多个锁当中产生死锁问题。
-
Redisson中的实现
1）利用hash结构记录线程id和重入次数
2）获取锁之后在原有的重入次数中加1，释放锁成功时再直接减1，直到重入次数为0时才可以将该锁的信息删除。
5、Redisson实现的分布式锁能否解决主从数据的一致性？（不能）
-
假如redis的集群架构有一个主节点（主库），用于写数据；两个从节点（从库），用于读数据。当主节点发生了写数据时，则需要将数据同步到两个从节点中。当Java应用获取锁往主库中写入数据后，还没来得及将数据同步到从库中，主库就宕机了（挂了），则此时就出现了主从数据不一致的情况。主库宕机后，redis使用的哨兵模式，则会从两个从库中选择一个作为主库，此时还能去获取锁，则出现了两个线程拥有同一把锁的情况，导致脏数据。
-
RedLock（红锁）：不能只在一个redis实例上创建锁，应该是在多个实例上创建（n / 2 + 1）个，避免在一个redis实例上加锁。但使用红锁，会导致业务实现比较复杂、性能差、运维繁琐。
-
Redisson实现的分布式锁不能解决主从数据的一致性，但是可以使用redisson提供的红锁来解决，红锁的性能太低，如果业务中硬性要求要保证数据的强一致性，建议采用zookeeper实现的分布式锁。
-
Redis 主要保证的是高可用性，zookeeper才可以保证数据的强一致性。
6、Redis分布式锁
三、Redis集群
1、Redis集群有哪些方案？
- Redis中提供的集群方案有三种：
1）主从复制：单节点redis的并发能力是有上限的，要进一步提高redis的并发能力，就需要搭建主从集群，实现读写分离。
2）哨兵模式：sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，用来实现主从集群自动故障恢复，可保证redis的高并发高可用。
3）分片集群：可解决海量数据存储问题、高并发写问题，
2、主从数据同步流程（主从复制原理）
-
主从同步：单节点redis的并发能力是有上限的，要进一步提高redis的并发能力，就需要搭建主从集群，实现读写分离，一般是一主多从，主节点负责写数据，从节点负责读数据，主节点写入数据之后，需要把数据同步到从节点中。
-
主从同步分为两个阶段：全量同步、增量同步。
-
主从全量同步：指从节点第一次与主节点建立连接时使用的同步，即全量同步。
1）从节点请求主节点同步数据，其中从节点会携带自己的replication id和offset偏移量。
replication id：数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的id，slave则会继承master节点的id。
offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大，slave完成同步时也会记录当前同步的offset，如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。
2）主节点判断是否第一次请求，主要判断的依据是，主节点和从节点是否是同一个replication id，如果不是，就说明是第一次同步，那主节点就会把自己的replication id和offset偏移量发送给从节点，让从节点与主节点的信息保持一致。
3）同时主节点会执行bgsave，生成rdb文件后，发送给从节点去执行，从节点先把自己的数据清空，然后执行主节点发送过来的rdb文件，这样就保持了一致。
4）如果在rdb生成执行期间，依然有请求到了主节点，主节点会以命令的方式记录到缓冲区，缓冲区是一个日志文件
5）最后把这个日志文件发送给从节点，这样就能保证主节点和从节点完全一致了，后期再同步数据时，都是依赖这个日志文件 -
主从增量同步：指当从节点服务重启之后，数据不一致时的同步
1）从节点会请求主节点同步数据，主节点还是判断是不是第一次请求，不是第一次就获取从节点的offset值
2）然后主节点从命令日志中获取offset值之后的数据，发送给从节点进行数据同步。
3、哨兵模式（保证redis的高并发高可用）
-
哨兵模式：实现了主从集群的自动故障恢复（监控、自动故障恢复、通知），如果master故障，sentinel（哨兵）会将一个slave提升为master。当故障实例恢复后也会以新的master为主，同时sentinel（哨兵）也充当redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给redis的客户端，即一般项目采用哨兵模式可保证redis的高并发高可用。
-
哨兵的作用：
1）集群监控：负责监控 redis master 和 slave 进程是否正常工作。sentinel（哨兵）会不断的检查master和slave是否按预期工作。
2）自动故障恢复：如果 master node 故障挂掉了，会自动转移到 slave node 上，将一个slave提升为master，当故障实例恢复后也以新的master为主。
3）消息通知：如果某个 redis 实例有故障，那么sentinel哨兵负责发送消息作为报警通知给管理员，sentinel充当redis客户端的服务发现来源，会将最新信息推送给redis的客户端。 -
服务状态监控：sentinel基于心跳机制监测服务状态，每隔1s向集群的每个实例发送ping命令
1）主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
2）客观下线：如果超过指定数量quorum的sentinel都认为该实例已经下线，则该实例客观下线，quorum值最好超过sentinel实例数量的一半。 -
哨兵选主规则：
1）首先判断主与从节点断开时间长短，如果超过指定值就排该从节点
2）然后判断slave-priority值，越小优先级越高
3）如果slave-priority一样，则判断slave节点的offset值，越大优先级越高
4）最后判断slave节点的运行id大小，越小优先级越高。
4、Redis集群脑裂，该怎么解决？
-
集群脑裂：指使用哨兵模式集群时，由于主节点master和从节点和sentinel（哨兵）处于不同的网络分区，使得sentinel没有心跳感知到主节点master，所以通过选举的方式提升了一个从节点slave为主节点master，这样就存在两个主节点，就像大脑分裂了一样，会导致客户端还在old master那里写入数据，新节点无法同步数据，当网络恢复后，sentinel（哨兵）会将老的主节点降为slave从节点，这时再从新的主节点同步数据，这会导致老的主节点中的大量数据丢失。
-
解决办法：可以修改redis的配置，可设置最少的slave节点个数，比如设置至少要有一个从节点才能同步数据；可设置主从数据复制和同步的延迟时间，达不到要求就拒绝请求，可避免大量数据丢失。
min-replicas-to-write 1 表示最少的slave节点为1个
min-replicas-max-lag 5 表示数据复制和同步的延迟不能超过5秒
5、redis的分片集群有什么作用？
- 分片集群主要解决海量数据存储的问题，集群中有多个master，每个master保存不同数据
- 每个master都可以设置多个slave节点，就可以继续增大集群的高并发能力。
- 同时每个master之间通过ping监测彼此健康状态，就类似于哨兵模式了。
- 当客户请求可以访问集群任意节点，最终都会被转发到正确节点。
6、redis分片集群中数据是怎么存储和读取的?
- redis分片集群引入了哈希槽（slot）的概念，redis集群有16384个哈希槽，集群中每个主节点绑定了一定范围的哈希槽范围，key通过CRC16校验后对16384取模来决定哪个槽，通过槽找到对应的节点进行存储。
7、Redis是单线程，为什么还那么快？
- Redis是纯内存操作，执行速度非常快
- 采用单线程，避免不必要的上下文切换可竞争条件，多线程还要考虑线程安全问题
- 使用I/O多路复用模型，非阻塞IO
- 例如 bgsave和bgrewriteaof 都是在后台执行操作，不影响主线程的正常使用，不会产生阻塞
8、IO多路复用模型
-
redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，I/O多路复用模型主要就是实现了高效的网络请求。
-
Linux系统中一个进程使用的内存情况划分部分：用户空间和内核空间
用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问。
内核空间可以执行特权命令（Ring0），调用一切系统资源。 -
常见的IO模型
1）阻塞IO（Blocking IO)
2）非阻塞IO（Nonblocking IO）
3）IO多路复用（IO Multiplexing） -
redis网络模型
-
Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区
写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备
读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区
