1. Redis数据过期后删除策略是什么
- 定期删除：Redis每隔一段时间，会随机检查一定数量的键，如果发现过期键，则将其删除。这种方式能够在后台持续清理过期数据，防止内存膨胀。
- 惰性删除：在每次访问键时，Redis检查该键是否过期，如果过期，则将其删除。这种策略保证了在使用过程中只删除不再需要的数据。
1. 定期删除细节
定期删除策略是Redis内部的一个定时任务，周期性（每100ms）扫描一些设置了过期时间的键。要注意，Redis并不会一次性扫描所有设置了过期时间的键，因为这样会消耗大量的CPU，
他会在每次扫描时限制扫描的时间和数量。以避免对性能产生过大的影响，因此，可能会有部分键过期了没有被及时删除。
每次获取20个key判断是否过期，如果发现过期的key占比超过25%则继续再拉20个，如果小于25%则停止。这里还有一个时间限制，即一次删除时间不超过25ms。即如果发现占比超过25%的时候，需要判断目前是否已经花了25ms，如果已经用了这么多时长也会结束。
2. 惰性删除优缺点
- 优点：可以减少CPU占用
- 缺点：如果一直么有查询一个key，则可能不会被删除。这样就容易造成内存泄漏。
3. 内存回收机制
实际上，当Redis内存使用达到设置的maxmemory限制时，也会触发内存回收机制。
此时会主动删除一些过期键和其他不需要的键，以释放内存。具体的删除策略有以下几种：
- volatile-lru: 从设置了过期时间的key中使用LRU算法删除
- allkeys-lru：从所有键中使用lru算法删除
- volatile-lfu: 从设置了过期时间的key中使用lfu(最少使用频率)算法删除
- allkeys-lfu
- volatile-random
- allkeys-random
- volatile-ttl: 从设置了过期时间的键中根据TTL（存活时间）删除键，优先删除存活时间最短的键
- noevicition
2. Redis的Lua脚本功能是什么？如何使用
Redis的Lua脚本功能允许用户在Redis服务器端执行自定义的Lua脚本，以实现原子操作和复杂逻辑。
核心点包括：
原子性：Lua脚本的所有命令在执行过程中是原子的，避免了并发修改带来的问题。减少网络往返次数：通过在服务器端执行脚本，减少了客户端和服务器之间的网络往返次数，提高了性能。复杂操作：可以在Lua脚本中执行复杂的逻辑，比如，批量更新、条件更新等。
Lua脚本本身不具备原子性，但是由于redis的命令是单线程执行的，他会把整个lua脚本作为一个命令执行，会阻塞期间接受到的其他命令，这就保证了Lua脚本的原子性。
Lua脚本使用示例
Redis通过EVAL命令执行Lua脚本，Lua脚本可以访问Redis中的键、执行命令和操作数据。
- KEYS: 表示传入的键名数组
- ARGV:表示传入的参数数组
>
3. Redis中Pipeline功能是什么
Redis的Pipeline功能允许客户端在一次网络请求中批量发送多个命令，以减少网络延迟并提高性能。通过将多个命令打包发送，客户端可以在不等待每个命令响应的情况下继续发送其他命令，从而显著提高吞吐量。
- 节省了网络传输时间
- 减少了Redis服务端上下文切换开销。
4. Redis中的BigKey问题是什么？如何解决？
Redis中的“big key”是指一个内存空间占用比较大的key，他的危害如下
内存分布不均：在集群模式下，不同slot分配到不同实例中，如果大key都映射到一个实例，则分布不均，查询效率也会受到影响。- 由于Redis单线程命令，操作大key耗时较长，从而导致Redis出现
其他命令阻塞问题。 - 大key对资源的占用巨大，在你进行网络IO传输的时候，导致
获取过程中产生的网络流量较大，从而产生网络传输时间延长设置网络传输发现阻塞现象，例如一个key 2MB，请求1000次。 客户端超时，因为操作大key耗时较长，可能导致客户端等待超时。
如何解决Big Key 问题
- 开发方面
- 对要存储的数据进行压缩，压缩之后存储
- 大化小，把大对象拆分成小对象，即将一个dakey拆分成若干个小key，降低单个key的内存大小。
- 使用合适的数据结构存储，比如一些用String存储的，可以转换为Hash等结构。
- 业务方面
- 可以根据实际情况，调整存储策略，只存一些必要的数据。
- 优化业务逻辑，从根源上避免大key产生，比如一些可以不展示的信息，直接移除。
- 数据分布方面
- 采用Redis集群方式部署，大key分散到不同服务器上面。
5. 如何解决Redis中热点key问题
Redis中的热点key问题是指某些key被频繁访问，导致Redis的压力过大，进而影响整体性能甚至导致集群节点故障。
解决热点key问题的主要方法包括
- 热点key拆分：将热点key数据拆分到多个key中，例如通过引入前缀，使得不同用户请求分散到多个key，避免集中访问单一key。
- 多级缓存：在Redis前增加其他缓存，如本地缓存，以减轻Redis压力。
- 读写分离：通过Redis主从复制，将读请求分发到多个从节点，从而减轻单节点压力
- 限流和降级：在热点key访问过高时，应用限流策略，减少对Redis请求。
6. Redis的持久化机制有哪些
RDB&AOF（redis持久化机制）
7. Redis的哨兵机制是什么
Redis的哨兵机制 是一种高可用性解决方案，用于监控Redis主从集群，自动完成主从切换，以实现故障启动恢复和通知。
主要功能包括
监控：哨兵不断监控Redis主节点和从节点的运行状态，定期发送PING请求检查节点是否正常。自动故障转移：当主节点发生故障时，哨兵会选举一个从节点提升为新的主节点，并通知客户端更新主节点的地址，从而实现高可用。通知：哨兵可以向系统管理员或其他服务发送通知，以便快速处理Redis实例的状态变化。
1. 哨兵机制的由来主从架构中，如果采用读写分离的模式，即主节点负责写请求，从节点负责读请求。假设，这个时候主节点宕机了，没有新的主节点顶替上来的话，就会出现很长一段时间写请求没响应的情况。
针对这个情况，便出现了哨兵这个机制，主要进行监控作用，如果主节点挂了，将从节点切换成主节点，从而最大限度的减少停机时间和数据丢失。
- 哨兵节点：主要作用是对Redis的主从服务节点进行监控，当主节点发生故障的时候，哨兵节点会选择一个合适的从节点升级为主节点，并通知其他从节点和客户端进行更新操作。
- Redis节点：主要包括master以及slave节点，就是Redis提供服务的实例。
2. 主动下线和客观下线
- 主观下线：Sentinel每隔1s会发送ping命令给所有节点。如果sentinel每隔一段时间还未收到对应节点的pong回复，就会认为这个节点主观下线。
- 客观下线：
只有主节点才有客观下线，从节点没有。假设目前有个主节点被一个sentinel判断主观下线了，但可能主节点并没有问题，只是因为网络抖动导致一台哨兵的误判。所以，此时哨兵需要问问他的队友，来确定这个主节点是不是真的出了问题。
因此，他会向其他哨兵发起投票，其他哨兵会判断主节点的状态进行投票。赞成或返回。
如果认为下线的总投票数超过一半，则判断该主节点客观下线，此时需要主从切换。而只有哨兵的leader才能操作主从切换。
3. 哨兵leader如何选举出来
哨兵leader节点的选举实际上涉及到分布式算法raft，判断主观下线的sentinel就是候选者，此时他想成为leader。如果同时有两个sentinel判断主观下线，那么他们都是候选人，一起竞争成为leader。
候选者会先投给自己一票，然后向其他sentinel发送命令让他们给自己投票，每个哨兵手里只有一票，投了一个之后就不能投别人了。
4. Redis主节点选举
选出哨兵leader之后，需要选出Redis主从集群中新的master节点。
首先，需要把已下线节点全部剔除，然后从正常的从节点中选择主节点。主要经过以下三个流程
- 根据从节点的优先级选择，优先选择优先级值比较小的节点。（优先级的值越小，优先级越高，优先级可通过slave-priority设置）。
- 如果节点的优先级相同，则查看进行主从复制的offset的值，即复制的偏移量，偏移量越大则优先级越高。
- 如果offset也相同，则只能比较ID号，选择ID号小的成为主节点。
选好主节点后，哨兵leader会让其他从节点全部成为新的master节点的salve节点。
8. Redis集群会出现脑裂问题吗
Redis集群存在脑裂问题的风险，特别是在网络分区的情况下，可能会导致同一集群出现多个主节点，导致数据不一致。
1. 什么是脑裂
脑裂是指在分布式系统中，由于网络分区或者其他问题导致系统中的多个节点误以为自己是唯一的主节点。这种情况会导致多个主节点同时提供写入服务，从而引起数据不一致。
导致脑裂出现原因主要是网络分区。
2. Redis中如何避免脑裂问题的发生
- min-slaves-to-write（最小同步副本数）: 设置主节点在至少有指定数量的从节点确认写操作的情况下执行写操作。
- min-slaves-max-lag（最大延迟）: 设置从节点的最大延迟，如果从节点的延迟超过这个值，则该从节点不会被记入min-slaves-to-write的计数中。
例如：当最小同步副本数设置为2，最大延迟设置为10时，主节点只有在至少有2个从节点延迟不超过10s的情况下才会接受写操作。
9. RedLock红锁
RedLock是Redis官方推荐的一种实现分布式锁的算法，适用于集群环境下。
RedLock基本思想
- 部署多个redis实例
- 客户端在大多数实例上请求锁，并在一定时间内获得成功，表示加锁成功。
- 使用redLock可以提供更高的容错性，即使部分Redis实例故障，仍然可以获得锁。
RedLock实现流程
- 客户端尝试在每个Redis实例上加锁，必须在有限时间内完成所有实例的加锁。
- 如果大多数实例（N/2+1）加锁成功，则表示加锁成功
- 否则，客户端将释放所有已经加锁的实例，重新尝试。
10. 分布式锁在未完成逻辑前过期怎么办
如果锁在未完成逻辑前就过期，此时可能会产生数据不一致问题。因为锁过期了，此时，如果再出现一个客户端争抢锁，即可拿到锁然后同时进行业务操作，这等于锁失效了。
看门狗机制
即再抢到锁之后，启动一个后台任务，该任务检查变量值，如果变量为false，表示该任务尚未执行结束，定时任务（看门狗）向redis进行锁的续期。如果任务执行完成，将共享变量设置为true，结束该后台任务。
redission实现的分布式锁就引入了看门狗机制。