Java面试篇：Redis分布式锁（执行流程，主从一致性，是否可重入），Redis集群方案（主从复制，哨兵模式，分片集群），Redis单线程性能分析（IO多路复用模型，Redis网络模型）

1.redis分布式锁

Redis实现分布式锁主要利用Redis的setnx命令。setnx是SET if not exists(如果不存在，则SET)的简写。

1.Redisson实现分布式锁如何合理的控制锁的有效时长?

在redisson的分布式锁中，提供了一个WatchDog(看门狗)，一个线程获取锁成功以后，WatchDog会给持有锁的线程续期（默认是每隔10秒续期一次)

在Redis实现分布式锁时，可以通过设置锁的过期时间来控制锁的有效时长。以下是一种合理的控制锁有效时长的方式：

1. 在获取锁时，使用Redis的set命令设置锁的键值对，并通过设置过期时间参数来指定锁的有效时长。

2. 设置过期时间时，可以根据业务需求来确定合适的有效时长。一般情况下，可以设置一个较短的有效时长，以防止锁长时间被占用而导致其他请求无法获取锁。

3. 在某些情况下，可能需要延长锁的有效时长。可以通过使用Redis的expire命令来更新锁的过期时间，将其延长至合理的时间范围内。

4. 如果在获取锁后，处理业务逻辑的时间超过了锁的有效时长，可以在业务逻辑处理完成后及时释放锁，以避免锁被其他请求长时间等待。

需要注意的是，在设置锁的过期时间时，需要确保操作的原子性，以避免在设置锁和设置过期时间之间发生异常导致的锁无法释放问题。可以使用Redis的set命令的NX和EX参数来实现原子性的操作。

2.Redis实现分布式锁的执行流程

1. 客户端发送请求给Redis，请求获取分布式锁。
2. Redis尝试在指定的键上设置一个带有超时时间的值作为锁，并返回设置成功与否的结果。
3. 如果设置成功，说明当前客户端获取到了分布式锁，并可以执行后续的业务逻辑；如果设置失败，则说明当前有其他客户端已经持有了该锁，需要等待锁释放。
4. 在获取到锁后，客户端执行业务逻辑。
5. 客户端执行完业务逻辑后，释放锁。
6. 客户端发送请求给Redis，请求释放分布式锁。
7. Redis根据客户端发送的请求，删除对应的锁键。
8. 客户端释放锁成功，其他等待获取锁的客户端可以继续尝试获取锁。
9. 如果客户端在获取锁的过程中发生了异常或崩溃，没有能够及时释放锁，可以设置一个超时时间，保证锁能在一定时间内自动释放，避免死锁的情况发生。

需要注意的是，Redis的分布式锁并不是严格意义上的互斥锁，因为Redis的单个命令是原子性的，但是在多个命令之间无法保证原子性。因此，在使用Redis实现分布式锁时，需要结合其他技术手段，如设置超时时间、使用Lua脚本等，来保证分布式锁的正确性和稳定性。

3.Redisson实现的分布式锁：主从一致性

问题：Redisson锁能解决主从数据一致的问题吗?
答：不能解决，但是可以使用redisson提供的红锁来解决，但是这样的话，性能就太低了、如果业务中非要保证数据的强一致性，建议采用zookeeper实现的分布式锁

RedLock(红锁):不能只在一个redis实例上创建锁，应该是在多个redis实例上创建锁(n /2+1)，避免在一个redis实例上加锁。

①RedLock（红锁）是一种用于防止云资源被未经授权的访问和使用的安全工具。它由云安全公司 RedLock 提供，并通过使用云环境的 API 锁定漏洞和错误配置来检测安全风险。
②RedLock 通过扫描云环境中的资源，包括云存储桶、虚拟机、容器等，并分析它们的配置和活动日志，以确定是否存在潜在的安全风险。它还可以检测到未经授权的访问、敏感数据泄露、异常活动和恶意行为等情况。
③RedLock 提供了实时的安全报告和警报，帮助用户及时发现和解决安全问题。它还提供了自动化的修复建议，以帮助用户迅速纠正漏洞和错误配置。
④RedLock 可以与各种云平台集成，包括亚马逊 Web 服务（AWS）、微软 Azure 和谷歌云平台，以提供全面的云安全解决方案。它帮助组织加强云安全，减少数据泄露和未经授权的访问风险。

4.Redisson的这个锁，可以重入吗?

可以重入，多个锁重入需要判断是否是当前线程，在redis中进行存储的时候使用的hash结构，来存储线程信息和重入的次数.

2.Redis集群方案

1.主从复制

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。一般都是一主多从，主节点负责写数据，从节点负责读数据

Replication ld:简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid,slave则会继承master节点的replid
offset:偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset,如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。

1.主从全量同步

1.从节点请求主节点同步数据（replication id、 offset )
2.主节点判断是否是第一次请求，是第一次就与从节点同步版本信息(replication id和offset)
3.主节点执行bgsave，生成rdb文件后，发送给从节点去执行
4.在rdb生成执行期间，主节点会以命令的方式记录到缓冲区（一个日志文件)
5.把生成之后的命令日志文件发送给从节点进行同步

2.主从增量同步(slave重启或后期数据变化)

1.从节点请求主节点同步数据，主节点判断不是第一次请求，不是第一次就获取从节点的offset值
2.主节点从命令日志中获取offset值之后的数据，发送给从节点进行数据同步

2.哨兵模式

问：怎么保证Redis的高并发高可用？

Redis提供了哨兵(Sentinel)机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下:

• 监控: Sentinel会不断检查您的master和slave是否按预期工作
• 自动故障恢复:如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
• 通知: Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

1.服务状态监控

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令:

• 主观下线:如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
• 客观下线:若超过指定数量（quorum)的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

2.哨兵选主规则

①首先判断主与从节点断开时间长短，如超过指定值就排该从节点。
②然后判断从节点的slave-priority值，越小优先级越高。
③如果slave-prority一样，则判断slave节点的offset值，越大优先级越高
④最后是判断slave节点的运行id大小，越小优先级越高。

3.redis集群（哨兵模式)脑裂

redis集群脑裂，该怎么解决呢?

集群脑裂是由于主节点和从节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到主节点，所以通过选举的方式提升了一个从节点为主，这样就存在了两个master，就像大脑分裂了一样，这样会导致客户端还在老的主节点那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将老的主节点降为从节点，这时再从新master同步数据，就会导致数据丢失

解决︰我们可以修改redis的配置，可以设置最少的从节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的数据丢失

3.分片集群

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决:

• 海量数据存储问题
• 高并发写的问题

使用分片集群可以解决上述问题，分片集群特征:

• 集群中有多个master，每个master保存不同数据。
• 每个master都可以有多个slave节点
• master之间通过ping监测彼此健康状态
• 客户端请求可以访问集群任意节点，最终都会被转发到正确节点

分片集群结构-数据读写

Redis分片集群引入了哈希槽的概念，Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

• Redis 分片集群引入了哈希槽的概念，Redis集群有16384个哈希槽
• 将16384个插槽分配到不同的实例
• 读写数据:根据key的有效部分计算哈希值，对16384取余(有效部分，如果key前面有大括号，大括号的内容就是有效部分，如果没有，则以key本身做为有效部分）余数做为插槽，寻找插槽所在的实例

3.Redis是单线程的，为什么还那么快？

• Redis是纯内存操作，执行速度非常快
• 采用单线程，避免不必要的上下文切换可竞争条件，多线程还要考虑线程安全问题
• 使用I/O多路复用模型，非阻塞lO

1. 能解释一下I/O多路复用模型?

Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度,I/O多路复用模型主要就是实现了高效的网络请求

2.用户空间和内核空间

①Linux系统中一个进程使用的内存情况划分两部分:内核空间、用户空间
②用户空间只能执行受限的命令(Ring3)，而且不能直接调用系统资源必须通过内核提供的接口来访问
③内核空间可以执行特权命令(Ring0)，调用一切系统资源

Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区:

• 写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备
• 读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

3.阻塞IO

阻塞IO就是两个阶段都必须阻塞等待:

阶段一:

• 用户进程尝试读取数据（比如网卡数据)
• 此时数据尚未到达，内核需要等待数据
• 此时用户进程也处于阻塞状态

阶段二:

• 数据到达并拷贝到内核缓冲区，代表已就绪
• 将内核数据拷贝到用户缓冲区
• 拷贝过程中，用户进程依然阻塞等待
• 拷贝完成，用户进程解除阻塞，处理数据

4.非阻塞IO

非阻塞lO的recvfrom操作会立即返回结果而不是阻塞用户进程。

阶段一:

• 用户进程尝试读取数据（比如网卡数据)
• 此时数据尚未到达，内核需要等待数据
• 返回异常给用户进程
• 用户进程拿到error后，再次尝试读取
• 循环往复，直到数据就绪

阶段二:

• 将内核数据拷贝到用户缓冲区
• 拷贝过程中，用户进程依然阻塞等待
• 拷贝完成，用户进程解除阻塞，处理数据

可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

5.IO多路复用:

是指利用单个线程来同时监听多个Socket，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。
目前的I/O多路复用都是采用的epoll模式实现，它会在通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间，不需要挨个遍历Socket来判断是否就绪，提升了性能。

阶段一:

• 用户进程调用select，指定要监听的Socket集合
• 内核监听对应的多个socket
• 任意一个或多个socket数据就绪则返回readable
• 此过程中用户进程阻塞

阶段二:

• 用户进程找到就绪的socket
• 依次调用recvfrom读取数据
• 内核将数据拷贝到用户空间
• 用户进程处理数据

不过监听Socket的方式、通知的方式又有多种实现，常见的有:

• select和poll只会通知用户进程有Socket就绪，但不确定具体是哪个Socket，需要用户进程逐个遍历Socket来确认
• epoll则会在通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间

6.Redis网络模型

Redis通过IO多路复用来提高网络性能，并且支持各种不同的多路复用实现，并且将这些实现进行封装，提供了统一的高性能事件库.

就是使用I/O多路复用结合事件的处理器来应对多个Socket请求

• 连接应答处理器
• 命令回复处理器，在Redis6.0之后，为了提升更好的性能，使用了多线程来处理回复事件
• 命令请求处理器，在Redis6.0之后，将命令的转换使用了多线程，增加命令转换速度，在命令执行的时候，依然是单线程