Redis(八股二弹)

1.redis数据类型和底层数据结构

2.Zset的底层数据结构

zset的底层数据结构有压缩列表和跳表

压缩列表的数据结构:

什么时候使用压缩列表?

1.有序集合保存的元素数量小于128
2.有序集合保存的所有元素的长度小于64字节

跳表:在链表的基础上增加多级索引,通过多级索引之间的转跳,实现了快速查找元素

跳表的时间复杂度为O(logn)

3.zset为什么用跳表而不用二叉树或者红黑树呢

Redis 使用跳表，因为它在内存中的查找、插入和删除操作简单且高效，适合实时数据处理和缓存应用。跳表的实现复杂度低且能节省内存。
MySQL 使用 B+ 树，因为它在磁盘存储中性能优异，能够高效地处理范围查询和减少磁盘 I/O。B+ 树适合大规模数据存储和复杂查询操作的需求。

1，内存消耗，avl树，红黑树每个节点至少存2个节点指针，而跳表的每个节点存的指针更少
2，操作简单，实现简单，avl树，红黑树都是有平衡左右子树的限制，如果树不平衡后会进行树的旋转，维护复杂，而跳表的每次插入与删除都比较简单，时间复杂度都是logn;
3，跳表范围查找的时候比较简单，先使用logn的复杂度查找到左边界，右边界直接往下遍历即可，而树的使用logn的复杂度查找到左边界后，又要使用中序遍历寻找有边界

4.redis的内存淘汰策略

redis内存达到了maxmemory的上限的时候,它的一种内存释放的行为

1.不淘汰数据的策略

当内存满了不足以写入数据时,不删除如何数据,后续所有的写入操作都会返回错误,读操作正常

适用于不允许数据丢失的情况

2.主动淘汰数据的策略

(1)在所有键中淘汰数据

allkeys-lru:淘汰最近最少使用的键

allkeys-lfu:淘汰最不经常使用的键(基于访问频率)

allkeys-random:随机淘汰一个键(所有键的访问频率都接近)

(2)在设置了过期时间的键中淘汰

volatile-lru:仅从设置了过期时间的键中,淘汰最近最少使用的键

volatile-lfu:仅从设置了过期时间的键中,淘汰最不经常使用的键(基于访问频率)

volatile-random:仅从设置了过期时间的键中,随机淘汰一个键(所有键的访问频率都接近)

volatile-ttl:仅从设置了过期时间的键中,淘汰剩余生存时间(ttl)最短的键(快过期的键)

5.redis主从复制的原理

redis主从复制包括全量复制和增量复制

全量复制发生在初始化阶段,从节点会主动向主节点发送一个同步请求,主节点收到请求会生成一份当前数据的快照,发送给从节点,从节点收到数据后进行加载之后,完成全量复制

增量节点发生在每一次master节点,发送数据变更的一个场景里面,会把变化的增量数据同步给从节点,增量复制是通过维护offset这样一个复制偏移量来实现的

每个redis都有其运行ID,运行ID由节点在启动时自动生成,并发送给从节点,当节点断开重连的时候,根据运行ID来判断同步

判断同步:

如果id相同,说明主从节点之间同步过,主节点会继续尝试增量复制(能不能增量复制还要看offset和复制积压缓冲区的情况)

如果不同,说明断开前同步的主节点不是当前节点,只能进行全量复制

6.redis分布式锁的实现原理

1.首先利用setnx来保证,如果key不存在才能获取到锁,如果key存在,则获取不到锁
2.然后还要使用lua脚本来保证多个redis操作的原子性
3.同时还要考虑到锁过期,所有需要额外的一个看门狗定时任务来监听锁是否需要续约
4.同时还要考虑redis节点挂掉的情况,所以需要采用红锁的方式同时向N/+个节点申请锁,都申请到了才证明获取锁成功,这样就算其中某个redis节点挂掉了,也不能获取锁

7.redis的集群策略

1.主从模式:这种模式比较简单,主库可以读写,并且会和从库进行数据同步,这种模式下,客户端直接连接主库或者某个从库,但是主库或从库宕机后,需要客户端手动维修改IP,另外,这种模式也难以进行扩容,整个集群所能存储的数据受到某台机器的内存容量,所以不可能支持特大数据量

2.哨兵模式:这种模式在主从的基础上新增了哨兵节点,当主库节点宕机后,哨兵会发现,然后从库中选择一个库作为主库,另外哨兵也可以作为集群,从而可以保证当一个哨兵节点宕机,还有其他哨兵可以继续工作,这种模式可以比较好的保证redis集群的高可用,但是仍然不能很好的解决redis容量上限问题

3.Cluster模式:是用的比较多的模式,它支持多主多从,这种模式会按照key进行槽位的分配,可以使得不同的key分散到不同的主节点上,利用这种模式可以使得整个集群支持更大的数据容量,同时每个主节点可以拥有自己的多个从节点,如果主节点宕机会从他的从节点选择一个新的主节点.

对于三种模式,如果redis要存的数据量不大,选择哨兵模式,如果redis要存的数据量大,并且需要持续的扩容,那么选择cluster模式.

8.redis中的大key怎么处理

1.把大key分割成多个小key 来存储,比如把一个大的hash结构分割成多个小的hash结构,每个小hash结构代表一部分数据,可以减少单个key的大小,去降低内存的压力

2.搭建Redis Cluster集群,把key分配到不同的hash slot槽所在的分片上,将单个redis节点的存储压力

3.如果已经存在了大key,可以做数据的拆分和迁移,按照业务规则和需求,将大key拆分成多个小的key,并发布到不同的redis实例上,迁移完成后,清理掉不需要使用的大key

4.考虑使用压缩算法进行压缩,去减少存储空间的占用,在存储数据之前对数据进行压缩,在读取的时候进行解压缩,以节省存储空间和减少网络传输的数据量