redis面试篇
|
中间件,数据库

9427 字
|
55 分钟
本文最后更新于292 天前，其中的信息可能已经过时，如有错误请发送邮件到big_fw@foxmail.com

redis主从

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。主从集群中有一个master节点、多个slave节点（现在叫replica）。当我们通过Redis的Java客户端访问主从集群时，应该做好路由：

  • 如果是写操作，应该访问master节点，master会自动将数据同步给slave节点
  • 如果是读操作，建议访问各个slave节点，从而分担并发压力

centos中效果如图：

可以看到，当前节点r1:7001的角色是master，有两个slave与其连接：

  • slave0：port是7002，也就是r2节点
  • slave1：port是7003，也就是r3节点

在r1这个节点上可以执行set命令（写操作），其它两个节点只能执行get命令（读操作）。也就是说读写操作已经分离了。

主从同步原理

概念

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

主从第一次建立连接时，会执行全量同步，将master节点的所有数据都拷贝给slave节点

步骤

  • slave节点请求增量同步
  • master节点判断replid，发现不一致，拒绝增量同步
  • master将完整内存数据生成RDB，发送RDB到slave
  • slave清空本地数据，加载master的RDB
  • master将RDB期间的命令记录在repl_baklog，并持续将log中的命令发送给slave
  • slave执行接收到的命令，保持与master之间的同步

注意：repl_baklog文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

可以从以下几个方面来优化Redis主从就集群：

  • 在master中配置repl-diskless-sync yes启用无磁盘复制，避免全量同步时的磁盘IO。
  • Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
  • 适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
  • 限制一个master上的slave节点数量，如果实在是太多slave，则可以采用主-从-从链式结构，减少master压力

简述全量同步和增量同步区别？

  • 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
  • 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

什么时候执行全量同步？

  • slave节点第一次连接master节点时
  • slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

什么时候执行增量同步？

  • slave节点断开又恢复，并且在repl_baklog中能找到offset时

哨兵原理

Redis提供了哨兵（Sentinel）机制来监控主从集群监控状态，确保集群的高可用性。

哨兵的作用如下：

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

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个节点发送ping命令，并通过实例的响应结果来做出判断：

  • 主观下线（sdown）：如果某sentinel节点发现某Redis节点未在规定时间响应，则认为该节点主观下线。
  • 客观下线(odown)：若超过指定数量（通过quorum设置）的sentinel都认为该节点主观下线，则该节点客观下线。quorum值最好超过Sentinel节点数量的一半，Sentinel节点数量至少3台。

一旦发现master故障，sentinel需要在salve中选择一个作为新的master，选择依据是这样的：

  • 首先会判断slave节点与master节点断开时间长短，如果超过down-after-milliseconds * 10则会排除该slave节点
  • 然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举（默认都是1）。
  • 如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
  • 最后是判断slave节点的run_id大小，越小优先级越高（通过info server可以查看run_id）。

假如master发生故障，slave1当选。则故障转移的流程如下：

1）sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master

2）sentinel给所有其它slave发送slaveof 192.168.150.101 7002 命令，让这些节点成为新master，也就是7002的slave节点，开始从新的master上同步数据。

3）最后，当故障节点恢复后会接收到哨兵信号，执行slaveof 192.168.150.101 7002命令，成为slave

Sentinel的三个作用是什么？

  • 集群监控
  • 故障恢复
  • 状态通知

Sentinel如何判断一个redis实例是否健康？

  • 每隔1秒发送一次ping命令，如果超过一定时间没有相向则认为是主观下线（sdown）
  • 如果大多数sentinel都认为实例主观下线，则判定服务客观下线（odown）

故障转移步骤有哪些？

  • 首先要在sentinel中选出一个leader，由leader执行failover
  • 选定一个slave作为新的master，执行slaveof noone，切换到master模式
  • 然后让所有节点都执行slaveof 新master
  • 修改故障节点配置，添加slaveof 新master

sentinel选举leader的依据是什么？

  • 票数超过sentinel节点数量一半
  • 票数超过quorum数量
  • 一般情况下最先发起failover的节点会当选

sentinel从slave中选取master的依据是什么？

  • 首先会判断slave节点与master节点断开时间长短，如果超过down-after-milliseconds * 10则会排除该slave节点
  • 然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举（默认都是1）。
  • 如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
  • 最后是判断slave节点的run_id大小，越小优先级越高（通过info server可以查看run_id）。

RedisTemplate

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

spring:
  redis:
    sentinel:
      master: hmaster # 集群名
      nodes: # 哨兵地址列表
        - 192.168.150.101:27001
        - 192.168.150.101:27002
        - 192.168.150.101:27003

@Bean
public LettuceClientConfigurationBuilderCustomizer clientConfigurationBuilderCustomizer(){
    return clientConfigurationBuilder -> clientConfigurationBuilder.readFrom(ReadFrom.REPLICA_PREFERRED);
}

分片集群

主从模式可以解决高可用、高并发读的问题。但依然有两个问题没有解决：

  • 海量数据存储
  • 高并发写

分片集群特征：

  • 集群中有多个master，每个master保存不同分片数据 ，解决海量数据存储问题
  • 每个master都可以有多个slave节点 ，确保高可用
  • master之间通过ping监测彼此健康状态 ，类似哨兵作用
  • 客户端请求可以访问集群任意节点，最终都会被转发到数据所在节点

很多数据分片都会采用一致性hash算法。而Redis则是利用散列插槽（hash slot）的方式实现数据分片。

在Redis集群中，共有16384个hash slots，集群中的每一个master节点都会分配一定数量的hash slots。

假设，7001节点分配到的插槽是0~5460，7002节点，分配到的插槽是5461~10922，7003节点，分配到的插槽是10923~16383

当我们读写数据时，Redis基于CRC16 算法对key做hash运算，得到的结果与16384取余，就计算出了这个key的slot值。然后到slot所在的Redis节点执行读写操作。

docker exec -it r1 bash
# 进入redis-cli
redis-cli -p 7001
set user jack # 计算出slot为5474在7002，会报错
# 通过7001连接集群
redis-cli -c -p 7001
set user jack # 自动跳转到7002

Redis分片集群如何判断某个key应该在哪个实例？

  • 将16384个插槽分配到不同的实例
  • 根据key计算哈希值，对16384取余
  • 余数作为插槽，寻找插槽所在实例即可

如何将同一类数据固定的保存在同一个Redis实例？

  • Redis计算key的插槽值时会判断key中是否包含{}，如果有则基于{}内的字符计算插槽
  • 数据的key中可以加入{类型}，例如key都以{typeId}为前缀，这样同类型数据计算的插槽一定相同
spring:
  redis:
    cluster:
      nodes:
        - 192.168.150.101:7001
        - 192.168.150.101:7002
        - 192.168.150.101:7003
        - 192.168.150.101:8001
        - 192.168.150.101:8002
        - 192.168.150.101:8003

数据结构

常用的Redis数据类型有5种，分别是：

  • String
  • List
  • Set
  • SortedSet
  • Hash

RedisObject

不管是任何一种数据类型，最终都会封装为RedisObject格式

编号编码方式说明
0OBJ_ENCODING_RAWraw编码动态字符串
1OBJ_ENCODING_INTlong类型的整数的字符串
2OBJ_ENCODING_HThash表（也叫dict）
3OBJ_ENCODING_ZIPMAP已废弃
4OBJ_ENCODING_LINKEDLIST双端链表
5OBJ_ENCODING_ZIPLIST压缩列表
6OBJ_ENCODING_INTSET整数集合
7OBJ_ENCODING_SKIPLIST跳表
8OBJ_ENCODING_EMBSTRembstr编码的动态字符串
9OBJ_ENCODING_QUICKLIST快速列表
10OBJ_ENCODING_STREAMStream流
11OBJ_ENCODING_LISTPACK紧凑列表

SkipList

  • 元素按照升序排列存储
  • 节点可能包含多个指针，指针跨度不同。 
//跳表的结构体
typedef struct zskiplist {
// 头尾节点指针
struct zskiplistNode *header, *tail;
// 节点数量
unsigned long length;
// 最大的索引层级
int level;
} zskiplist; 
//跳表中节点的结构体
typedef struct zskiplistNode {
sds ele; // 节点存储的字符串
double score;// 节点分数，排序、查找用
struct zskiplistNode *backward; // 前一个节点指针
struct zskiplistLevel {
struct zskiplistNode *forward; // 下一个节点指针
unsigned long span; // 索引跨度
} level[]; // 多级索引数组
} zskiplistNode;

SortedSet

Redis的SortedSet底层的数据结构是怎样的？

SortedSet是有序集合，底层的存储的每个数据都包含element和score两个值。score是得分，element则是字符串值。SortedSet会根据每个element的score值排序，形成有序集合。

它支持的操作很多，比如：

  • 根据element查询score值
  • 按照score值升序或降序查询element

要实现根据element查询对应的score值，就必须实现element与score之间的键值映射。SortedSet底层是基于HashTable来实现的。

要实现对score值排序，并且查询效率还高，就需要有一种高效的有序数据结构，SortedSet是基于跳表实现的。

加分项：因为SortedSet底层需要用到两种数据结构，对内存占用比较高。因此Redis底层会对SortedSet中的元素大小做判断。如果元素大小小于128且每个元素都小于64字节，SortedSet底层会采用ZipList，也就是压缩列表来代替HashTable和SkipList

不过，ZipList存在连锁更新问题，因此而在Redis7.0版本以后，ZipList又被替换为Listpack（紧凑列表）。

内存回收

我们可以通过修改redis.conf文件，添加下面的配置来配置Redis的最大内存： maxmemory 1gb

当内存达到上限，就无法存储更多数据了。因此，Redis内部会有两套内存回收的策略：

  • 内存过期策略
  • 内存淘汰策略

Redis的过期KEY删除策略有两种：

  • 惰性删除：过期后不会立刻删除，访问时删除
  • 周期删除：通过一个定时任务，周期性的抽样部分过期的key，然后执行删除

执行周期有两种：

  • SLOW模式： Redis会设置一个定时任务serverCron()，按照server.hz的频率来执行过期key清理，默认频率10，每次不超过25ms
  • FAST模式： Redis的每个事件循环前执行过期key清理（事件循环就是NIO事件处理的循环）。默认不少于2ms，每次不超过1ms

内存淘汰

对于某些特别依赖于Redis的项目而言，仅仅依靠过期KEY清理是不够的，内存可能很快就达到上限。因此Redis允许设置内存告警阈值，当内存使用达到阈值时就会主动挑选部分KEY删除以释放更多内存。这叫做内存淘汰机制。

Redis支持8种不同的内存淘汰策略：

  • noeviction： 不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略。
  • volatile-ttl： 对设置了TTL的key，比较key的剩余TTL值，TTL越小越先被淘汰
  • allkeys-random：对全体key ，随机进行淘汰。也就是直接从db->dict中随机挑选
  • volatile-random：对设置了TTL的key ，随机进行淘汰。也就是从db->expires中随机挑选。
  • allkeys-lru： 对全体key，基于LRU算法进行淘汰
  • volatile-lru： 对设置了TTL的key，基于LRU算法进行淘汰
  • allkeys-lfu： 对全体key，基于LFU算法进行淘汰
  • volatile-lfu： 对设置了TTL的key，基于LFI算法进行淘汰

两种算法：

  • LRU（Least Recently Used），最近最久未使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
  • LFU（Least Frequently Used），最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。

Redis如何判断KEY是否过期呢？

答：在Redis中会有两个Dict，也就是HashTable，其中一个记录KEY-VALUE键值对，另一个记录KEY和过期时间。要判断一个KEY是否过期，只需要到记录过期时间的Dict中根据KEY查询即可。

Redis何时删除过期KEY？如何删除？

答：Redis的过期KEY处理有两种策略，分别是惰性删除和周期删除。

惰性删除是指在每次用户访问某个KEY时，判断KEY的过期时间：如果过期则删除；如果未过期则忽略。

周期删除有两种模式：

  • SLOW模式：通过一个定时任务，定期的抽样部分带有TTL的KEY，判断其是否过期。默认情况下定时任务的执行频率是每秒10次，但每次执行不能超过25毫秒。如果执行抽样后发现时间还有剩余，并且过期KEY的比例较高，则会多次抽样。
  • FAST模式：在Redis每次处理NIO事件之前，都会抽样部分带有TTL的KEY，判断是否过期，因此执行频率较高。但是每次执行时长不能超过1ms，如果时间充足并且过期KEY比例过高，也会多次抽样

当Redis内存不足时会怎么做？

答：这取决于配置的内存淘汰策略，Redis支持很多种内存淘汰策略，例如LRU、LFU、Random. 但默认的策略是直接拒绝新的写入请求。而如果设置了其它策略，则会在每次执行命令后判断占用内存是否达到阈值。如果达到阈值则会基于配置的淘汰策略尝试进行内存淘汰，直到占用内存小于阈值为止。

那你能聊聊LRU和LFU吗？

答：LRU是最近最久未使用。Redis的Key都是RedisObject，当启用LRU算法后，Redis会在Key的头信息中使用24个bit记录每个key的最近一次使用的时间lru。每次需要内存淘汰时，就会抽样一部分KEY，找出其中空闲时间最长的，也就是now - lru结果最大的，然后将其删除。如果内存依然不足，就重复这个过程。

由于采用了抽样来计算，这种算法只能说是一种近似LRU算法。因此在Redis4.0以后又引入了LFU算法，这种算法是统计最近最少使用，也就是按key的访问频率来统计。当启用LFU算法后，Redis会在key的头信息中使用24bit记录最近一次使用时间和逻辑访问频率。其中高16位是以分钟为单位的最近访问时间，后8位是逻辑访问次数。与LFU类似，每次需要内存淘汰时，就会抽样一部分KEY，找出其中逻辑访问次数最小的，将其淘汰。

面试题：逻辑访问次数是如何计算的？

答：由于记录访问次数的只有8bit，即便是无符号数，最大值只有255，不可能记录真实的访问次数。因此Redis统计的其实是逻辑访问次数。这其中有一个计算公式，会根据当前的访问次数做计算，结果要么是次数+1，要么是次数不变。但随着当前访问次数越大，+1的概率也会越低，并且最大值不超过255.

除此以外，逻辑访问次数还有一个衰减周期，默认为1分钟，即每隔1分钟逻辑访问次数会-1。这样逻辑访问次数就能基本反映出一个key的访问热度了。

缓存问题

缓存一致性

缓存的通用模型有三种：

  • Cache Aside：有缓存调用者自己维护数据库与缓存的一致性。即：
    • 查询时：命中则直接返回，未命中则查询数据库并写入缓存
    • 更新时：更新数据库并删除缓存，查询时自然会更新缓存
  • Read/Write Through：数据库自己维护一份缓存，底层实现对调用者透明。底层实现：
    • 查询时：命中则直接返回，未命中则查询数据库并写入缓存
    • 更新时：判断缓存是否存在，不存在直接更新数据库。存在则更新缓存，同步更新数据库
  • Write Behind Cahing：读写操作都直接操作缓存，由线程异步的将缓存数据同步到数据库

缓存穿透

很多线程频繁的访问一个数据库中也不存在的数据。由于缓存不可能生效，那么所有的请求都访问数据库，可能就会导致数据库因过高的压力而宕机。

解决这个问题有两种思路：

  • 缓存空值，设置TTL    优点：实现简单，维护方便    缺点：额外的内存消耗
  • 布隆过滤器

注意：布隆过滤首先需要一个很长的bit数组，默认数组中每一位都是0。 然后还需要K个hash函数，将元素基于这些hash函数做运算的结果映射到bit数组的不同位置，并将这些位置置为1。当布隆过滤器认为元素不存在时，它肯定不存在；当布隆过滤器认为元素存在时，它可能存在，也可能不存在

缓存雪崩

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

常见的解决方案有：

  • 给不同的Key的TTL添加随机值，这样KEY的过期时间不同，不会大量KEY同时过期
  • 利用Redis集群提高服务的可用性，避免缓存服务宕机
  • 给缓存业务添加降级限流策略
  • 给业务添加多级缓存，比如先查询本地缓存，本地缓存未命中再查询Redis，Redis未命中再查询数据库。即便Redis宕机，也还有本地缓存可以抗压力

缓存击穿

缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。

常见的解决方案有两种：

  • 互斥锁：给重建缓存逻辑加锁，避免多线程同时指向
  • 逻辑过期：热点key不要设置过期时间，在活动结束后手动删除。

如何保证缓存的双写一致性？

答：缓存的双写一致性很难保证强一致，只能尽可能降低不一致的概率，确保最终一致。我们项目中采用的是Cache Aside模式。简单来说，就是在更新数据库之后删除缓存；在查询时先查询缓存，如果未命中则查询数据库并写入缓存。同时我们会给缓存设置过期时间作为兜底方案，如果真的出现了不一致的情况，也可以通过缓存过期来保证最终一致。

为什么不采用延迟双删机制？

答：延迟双删的第一次删除并没有实际意义，第二次采用延迟删除主要是解决数据库主从同步的延迟问题，我认为这是数据库主从的一致性问题，与缓存同步无关。既然主节点数据已经更新，Redis的缓存理应更新。而且延迟双删会增加缓存业务复杂度，也没能完全避免缓存一致性问题，投入回报比太低。

如何解决缓存穿透问题？

答：缓存穿透也可以说是穿透攻击，具体来说是因为请求访问到了数据库不存在的值，这样缓存无法命中，必然访问数据库。如果高并发的访问这样的接口，会给数据库带来巨大压力。

我们项目中都是基于布隆过滤器来解决缓存穿透问题的，当缓存未命中时基于布隆过滤器判断数据是否存在。如果不存在则不去访问数据库。

当然，也可以使用缓存空值的方式解决，不过这种方案比较浪费内存。

来源：黑马程序员Redis面试篇

其它

为什么要用 redis ？为什么要用缓存？

高性能：

假如用户第一次访问数据库中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据存在缓存中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

高并发：

直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。

为什么要用 redis 而不用 map/guava 做缓存?

缓存分为本地缓存和分布式缓存。以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。

使用 redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性。缺点是需要保持 redis 或 memcached服务的高可用，整个程序架构上较为复杂。

redis 的线程模型是怎么样的？

redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，根据 socket 上的事件来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分：

  • 多个 socket
  • IO 多路复用程序
  • 文件事件分派器
  • 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器） 多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

redis 和 memcached 的区别？

存储方式不同：memcache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小；Redis 有部份存在硬盘上，这样能保证数据的持久性。

数据支持类型：memcache 对数据类型支持相对简单；Redis 有复杂的数据类型。

使用底层模型不同：它们之间底层实现方式，以及与客户端之间通信的应用协议不一样，Redis 自己构建了 vm 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。 value 值大小不同：Redis 最大可以达到 1gb；memcache 只有 1mb。

如何实现 redis 事务？

Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的可靠性和安全性。在 Redis 中，事务总是具有原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation），并且当 Redis 运行在某种特定的持久化模式下时，事务也具有持久性（Durability）。

什么是 RedLock？

获取当前时间（start）。

依次向 N 个 Redis节点请求锁。请求锁的方式与从单节点 Redis获取锁的方式一致。为了保证在某个 Redis节点不可用时该算法能够继续运行，获取锁的操作都需要设置超时时间，需要保证该超时时间远小于锁的有效时间。这样才能保证客户端在向某个 Redis节点获取锁失败之后，可以立刻尝试下一个节点。

计算获取锁的过程总共消耗多长时间（consumeTime = end – start）。如果客户端从大多数 Redis节点（>= N/2 + 1) 成功获取锁，并且获取锁总时长没有超过锁的有效时间，这种情况下，客户端会认为获取锁成功，否则，获取锁失败。

如果最终获取锁成功，锁的有效时间应该重新设置为锁最初的有效时间减去 consumeTime。

如果最终获取锁失败，客户端应该立刻向所有 Redis节点发起释放锁的请求。

说说 Redis 都有哪些应用场景？

缓存：这应该是 Redis 最主要的功能了，也是大型网站必备机制，合理地使用缓存不仅可以加 快数据的访问速度，而且能够有效地降低后端数据源的压力。

共享Session：对于一些依赖 session 功能的服务来说，如果需要从单机变成集群的话，可以选择 redis 来统一管理 session。

消息队列系统：消息队列系统可以说是一个大型网站的必备基础组件，因为其具有业务 解耦、非实时业务削峰等特性。Redis提供了发布订阅功能和阻塞队列的功 能，虽然和专业的消息队列比还不够足够强大，但是对于一般的消息队列功 能基本可以满足。比如在分布式爬虫系统中，使用 redis 来统一管理 url队列。

分布式锁：在分布式服务中。可以利用Redis的setnx功能来编写分布式的锁，虽然这个可能不是太常用。 当然还有诸如排行榜、点赞功能都可以使用 Redis 来实现，但是 Redis 也不是什么都可以做，比如数据量特别大时，不适合 Redis，我们知道 Redis 是基于内存的，虽然内存很便宜，但是如果你每天的数据量特别大，比如几亿条的用户行为日志数据，用 Redis 来存储的话，成本相当的高。

单线程的 Redis 为什么这么快？

Redis 有多快？官方给出的答案是读写速度 10万/秒，如果说这是在单线程情况下跑出来的成绩，你会不会惊讶？为什么单线程的 Redis 速度这么快？原因有以下几点：

纯内存操作：

  • Redis 是完全基于内存的，所以读写效率非常的高，当然 Redis 存在持久化操作，在持久化操作是都是 fork 子进程和利用 Linux 系统的页缓存技术来完成，并不会影响 Redis 的性能。
  • 单线程操作：单线程并不是坏事，单线程可以避免了频繁的上下文切换，频繁的上下文切换也会影响性能的。
  • 合理高效的数据结构
  • 采用了非阻塞 I/O 多路复用机制：多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。

说一说 Redis 的数据过期淘汰策略？

Redis 中数据过期策略采用定期删除+惰性删除策略。

1、定期删除、惰性删除策略是什么？

  • 定期删除策略：Redis 启用一个定时器定时监视所有的 key，判断key是否过期，过期的话就删除。这种策略可以保证过期的 key 最终都会被删除，但是也存在严重的缺点：每次都遍历内存中所有的数据，非常消耗 CPU 资源，并且当 key 已过期，但是定时器还处于未唤起状态，这段时间内 key 仍然可以用。
  • 惰性删除策略：在获取 key 时，先判断 key 是否过期，如果过期则删除。这种方式存在一个缺点：如果这个 key 一直未被使用，那么它一直在内存中，其实它已经过期了，会浪费大量的空间。

2、定期删除+惰性删除策略是如何工作的？

这两种策略天然的互补，结合起来之后，定时删除策略就发生了一些改变，不在是每次扫描全部的 key 了，而是随机抽取一部分 key 进行检查，这样就降低了对 CPU 资源的损耗，惰性删除策略互补了为检查到的key，基本上满足了所有要求。

但是有时候就是那么的巧，既没有被定时器抽取到，又没有被使用，这些数据又如何从内存中消失？没关系，还有内存淘汰机制，当内存不够用时，内存淘汰机制就会上场。Redis 内存淘汰机制有以下几种策略：

  • volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
  • volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
  • volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
  • allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
  • allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
  • no-eviction：禁止驱逐数据，永不过期，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！（默认值）

4.0版本后增加以下两种：

  • volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
  • allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key

手写一个 LRU 算法

class LRUCache<K, V> extends LinkedHashMap<K, V> {
    private final int CACHE_SIZE;
​
    /**
     * 传递进来最多能缓存多少数据
     *
     * @param cacheSize 缓存大小
     */
    public LRUCache(int cacheSize) {
        // true 表示让 linkedHashMap 按照访问顺序来进行排序，最近访问的放在头部，最老访问的放在尾部。
        super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
        CACHE_SIZE = cacheSize;
    }
​
    @Override
    protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
        // 当 map中的数据量大于指定的缓存个数的时候，就自动删除最老的数据。
        return size() > CACHE_SIZE;
    }
}

jedis 和 Redisson 有哪些区别？

jedis：提供了比较全面的 Redis 命令的支持。

Redisson：实现了分布式和可扩展的 Java 数据结构，与 jedis 相比 Redisson 的功能相对简单，不支持排序、事务、管道、分区等 Redis 特性。

请问Redis的rehash怎么做的，为什么要渐进rehash，渐进rehash又是怎么实现的?

因为redis是单线程，当K很多时，如果一次性将键值对全部rehash，庞大的计算量会影响服务器性能，甚至可能会导致服务器在一段时间内停止服务。不可能一步完成整个rehash操作，所以redis是分多次、渐进式的rehash。渐进性哈希分为两种：

1）操作redis时，额外做一步rehash

对redis做读取、插入、删除等操作时，会把位于table[dict->rehashidx]位置的链表移动到新的dictht中，然后把rehashidx做加一操作，移动到后面一个槽位。

2）后台定时任务调用rehash

后台定时任务rehash调用链，同时可以通过server.hz控制rehash调用频率

请问Redis的数据类型底层怎么实现?

1）字符串：整数值、embstr编码的简单动态字符串、简单动态字符串（SDS)

2）列表：压缩列表、双端链表

3）哈希：压缩列表、字典

4）集合：整数集合、字典

5）有序集合：压缩列表、跳跃表和字典

如果觉得本文对您有所帮助，那这将是对我最大的鼓励，期待您留下您宝贵的评论。
redis面试
暂无评论

发送评论 编辑评论 


				

			

						

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
							
													

					

				

			

			
			

				

					
				

			

				

											

							
							
						

																

							
							
						

																

							
							
						

										
					
									

			

			
			
		

	






上一篇
下一篇 

                    

                    
			        推荐文章
		            

		            

							
MySQL进阶

							
							

							
Java基础相关问题（总结）

							
							

							
redis基础

							
							

							
Redis持久化

							
							

							
注册中心

							
							

							
Elasticsearch

							
							

							
Mysql数据库基础知识