Redis

  1. 数据结构
  2. 缓存穿透、缓存击穿、缓存雪崩
  3. 实现分布式互斥锁
  4. RDB、AOF原理
  5. 渐进式rehash
  6. 跳跃表
  7. 布隆过滤器
  8. 哨兵模式、集群模式 
  9. 脑裂问题

Redis数据类型

  1. String
  2. Hash
  3. List
  4. Set
  5. Zset--使用跳表实现,时间复杂度为logn

缓存击穿、缓存穿透、缓存雪崩

缓存击穿--单个热点key失效,导致针对该key的请求直接打到数据库中;

解决办法:热点数据永不过期,加互斥锁

缓存穿透--请求不存在的key,访问直接到达数据库;

解决办法--缓存空值,布隆过滤器,业务参数合法性检验

缓存雪崩--大量热点key同时失效,导致大量请求落到数据库上

解决办法--热点数据永不过期,同一批热点数据失效时间加上随机值;

分布式互斥锁

SET key_name my_random_value NX PX 30000   

redlock原理--

  1. 获取当前时间戳,并一次从各个主节点中获取锁
  2. 要求获取锁的等待时间远小于锁的失效时间,这样某个节点获取失败之后及时从下一个节点获取,避免因单节点挂掉导致整个获取锁操作失败
  3. 如果获取到大于一半节点的锁,并且此时锁未失效(锁的实际时间=设置的锁的有效时间-获取锁的时间)则加锁成功,
  4. 获取锁失败后所有节点都会释放锁;
  5. 推荐为奇数个节点的原因是防止两个进程各获取一半节点数,导致两个线程都加锁失败;

        redlock存在的问题--如果某个主节点宕机且没来得及将锁信息同步到从节点,导致后来的线程仍然可以加锁成功;

RDB,AOF原理

RDB--主进程fork出一个子进程,子进程与主进程共享内存(写时复制ROW)进行备份

写时复制技术:当RDB进行时候,如果对某个key进行修改,则主进程会将被修改key所在的页拷贝一份,然后对该拷贝的副本进行修改,RDB备份的任然是备份开始前的数据;RDB完成之后将该页替换回去;

也就是说在复制的时候会出现页面分离导致内存增长的情况;

AOF--命令记录,时间间隔一般为1秒一次,当AOF文件过大时会发生AOF文件重写;

AOF重写时如果发生数据修改,则将修改命令记录在aof_rewrite_buff中,当AOF重写完成之后才会追加到新的AOF文件中;

渐进式rehash

redis中使用链接法解决哈希碰撞--整个机制和JDK中的hashmap很像;

rehash在扩容和缩容的时候都会触发--Redis在少于10%的时候会触发缩容;

负载因子,redis中rehash是由主线程完成的,为了避免主线程阻塞时间过长,Redis每次在数据访问的时候进行rehash操作,并记录当前rehash的索引保持进度;

在rehash过程中数据修改操作会同时对ht[0]和ht[1]操作,保证数据一致性;

你可能感兴趣的:(redis,面试,数据库)