Java面试——Redis相关

Redis 底层数据结构

字符串底层存储

在Redis 中&＃xff0c;字符串有三种存储编码方式&＃xff1a; int编码 、embstr编码和raw编码

int编码
当value是一个整数且值大小不超过8个字节&＃xff0c;就会是哟红int编码&＃xff0c;ptr直接存储数值

embstr 编码

embstr对象用于存储比较短的字符串&＃xff0c;embstr编码中RedisObject结构与ptr指向的SDS 结构在内存中是连续的&＃xff0c;内存分配次数和内存释放次数均是一次。
raw编码会分别调用两次内存分配函数来分别创建RedisObject结构个SDS结构。

hash对象

Redis中&＃xff0c;hash类型的value可以是一个hash表&＃xff0c;底层编码可以是ziplist&＃xff0c;也可以是hashtable。
默认情况下&＃xff0c;当元素个数小于512个时&＃xff0c;底层使用ziplist存储数据。

ziplist
元素保存的字符串长度较短且元素个数较少。&＃xff08;长度小于64字节&＃xff0c;个数小于512&＃xff09;&＃xff0c;出于节约内存考虑&＃xff0c;hash表会使用ziplist作为底层实现&＃xff0c;ziplist是一块连续的内存&＃xff0c;里面每一个节点保存了对应的key和value&＃xff0c;然后每个节点很紧凑地存储在一起。
优点是&＃xff1a; 没有冗余空间
缺点是&＃xff1a; 插入新元素需要调用realloc扩展内存&＃xff0c;这可能会导致内存重分配

hashtable

元素比较多是就会使用hashtable编码作为底层实现。此时RedisObject的ptr指针指向一个dict结构&＃xff0c;dict结构中的ht数组有两个元素h[0]和h[1]。通常h[0]保存键值对&＃xff0c;h[1]只在渐进式rehash时使用&＃xff0c;hashtable是通过链地址法来解决冲突的。

Zset

Zset在存储时会将元素按照score从低到高排列&＃xff0c;底层是通过跳表实现的。

ziplist
当元素较少时&＃xff08;元素长度小于64字节&＃xff0c;且元素个数小于128&＃xff09;&＃xff0c;Zset的底层编码使用ziplist实现&＃xff0c;所有元素按照score从低到高排序。

skiplist &＃43; dict
当元素较多时&＃xff0c;使用skiplist &＃43; dict来实现。skiplist存储元素的值和score&＃xff0c;并且将所有元素按照分值有序排列。便于以O(logN)的时间复杂度插入&＃xff0c;删除&＃xff0c;更新&＃xff0c;及根据Score进行范围性查找。

dict存储元素的值和Score的映射关系&＃xff0c;便于以O(1)的时间复杂度查找元素对应的分值。

跳表

跳表就是层次化的链表结构&＃xff0c;它由多个链表组成。只有底层的链表保存节点数据&＃xff0c;一般来说每两个节点选出一个节点作为下一级索引的节点&＃xff0c;让下一级 索引的节点数量为本机索引节点数量的一半。依次类推直至最顶层索引节点数为1。
原理是每次查找数据时&＃xff0c;先在最上层查找&＃xff0c;然后再定位到下一层&＃xff0c;层层定位&＃xff0c;直至最终找到目标数据。这种方式不用遍历整个链表&＃xff0c;而是跳跃着差&＃xff0c;这样就使得查找时间复杂度退化到了logn

为什么不使用List、红黑树或平衡二叉树呢&＃xff1f;

List是顺序㽾&＃xff0c;访问速度很快&＃xff0c;但是添加和删除操作是O&＃xff08;N&＃xff09;操作。至于红黑树和平衡二叉树&＃xff0c;每次更新redis的值&＃xff0c;都要消耗O(logn)的复杂度调整树结构&＃xff0c;而跳跃表只需要调整局部链表结构就行&＃xff0c;显然跳跃表更适合。
跳跃表支持平均O(logN)、最坏O(N)的复杂度进行节点查找&＃xff0c;还可以通过顺序性操作来批量处理节点。
在大部分情况下&＃xff0c;跳跃表的效率与平衡树媲美&＃xff0c;但是跳跃表的实现要比平衡树要来得更为简单。

Redis 常用数据结构底层实现

缓存雪崩

重复排队、并发超卖、数据不一致

redis分布式锁

1. 单机多线程下存在并发问题。 – 在JVM层面加锁&＃xff0c;如synchronized或ReentrantLock
2. 分布式部署下存在超卖问题。 --使用Redis分布式锁&＃xff0c;加解锁。

String value &＃61; UUID.random().toString();
Boolean flag &＃61; stringRedisTemplate.opsForValue().setIfAbsent(REDIS_LOCK, value); //加锁
stringRedisTemplate.delte(REDIS_LOCK)

3. 秒杀业务逻辑代码块出现异常时可能无法释放掉锁。 — 增加try -catch 语句块 在finally代码块释放锁
4. 部署了秒杀服务的服务器宕机 – 对lockkey 增加过期时间的设定
   5. 原子性考虑。 加锁和设置过期时间非原子操作
   

EX seconds – Set the specified expire time, in seconds.
PX milliseconds – Set the specified expire time, in milliseconds.

6. 误删其他事务的锁。 必须在删除锁之前判断是否是自己的加的锁。
   
   
7. 判断是否是自己加的锁 与 解锁非原子性操作&＃xff0c;那么会出现判断加锁与解锁不是同一个客户端导致误解锁

• 利用LUA脚本
  

• 使用Redis的事务

仍然存在 redisLock 过期时间小于业务执行时间的问题&＃xff0c;也就是如何实现分布式锁的续期问题。
再者在集群环境下还存在Redis的主从不一致

Redison

9. 在超高并发下&＃xff0c;可能出现IllegalMonitorStateException

select … for update后&＃xff0c;对所在行加了互斥锁&＃xff0c;而你使用select …在Innodb里是快照读&＃xff0c;是不涉及到锁的问题的&＃xff0c;如果想要验证加锁是否成功&＃xff0c;需要对查询加共享锁 lock in share mode或互斥锁for update

注意需要两个会话都开启事务&＃xff1a;

select * from tmp_file_bk limit 0,10 for update;

之后会话2&＃xff0c;使用

select * from tmp_file_bk where id &＃61; 106 lock in share mode ;

也无法访问到