笔记里有大量图片帮助你快速理解Redis

因为上传图片很麻烦这是无图片版的

可以在评论区留言，我会免费发送给你有图片版的笔记。

Redis简介

Redis诞生于2009年全称是Remote Dictionary Server，远程词典服务器，是一个基于内存的键值型NoSQL数据库。

特征：

• 键值（key-value）型，value支持多种不同数据结构，功能丰富。

• 单线程，每个命令具备原子性。

• 低延迟，速度快（基于内存，IO多路复用，良好的编码）。

• 支持数据持久化。

• 支持主从集群，分片集群。

• 支持多语言客户端。

Redis数据结构介绍

Redis是一个key-value的数据库，key一般是String类型，不过value的类型多种多样：

Redis通用命令

通用指令是部分数据类型的，都可以使用的指令，常见的有：

• KEYS：查看符合模板的key，不建议在生产环境设备上使用（因为redis是单线程的，只能同时处理一条指令，如果数据量大的情况下，查询所有会造成巨大的性能消耗，产生堵塞）。

• DEL：删除一个指定的key。

• EXISTS：判断key是否存在。

• EXPIRE：给一个key设置有效期，有效期到期时该key会被自动删除。

• TTL：查看一个KEY的剩余有效期。

Redis类型

String类型

String类型，也就是字符串类型，是Redis中最简单的存储类型。

其value是字符串，不过根据字符串的格式不同，又可以分为3类：

• string：普通字符串

• int：整数类型，可以做自增、自减操作

• float：浮点类型，可以做自增、自减操作

不管是哪种格式，底层都是字节数组形式存储，只不过是编码方式不同。字符串类型的最大空间不能超过512m。

String类型的常见命令

• SET：添加或者修改已经存在的一个String类型的键值对

• GET：根据key获取String类型的value

• MSET：批量添加多个String类型的键值对

• MGET：根据多个key获取多个String类型的value

• INCR：让一个整型的key自增1

• INCRBY：让一个整型的key自增并指定步长，例如：incrby num 2 让num值自增2

• INCRBYFLOAT：让一个浮点类型的数字自增并指定步长

• SETNX：添加一个String类型的键值对，前提是这个key不存在，否则不执行

• SETEX：添加一个String类型的键值对，并且指定有效期

key的结构

String类型总结

String类型的三种格式：

• 字符串

• int

• float

Redis的key的格式：

• [项目名] : [业务名] : [类型] : [id]

Hash类型

Hash类型，也叫散列，其value是一个无序字典，类似于Java中的HashMap结构。

String结构是将对象序列化为JSON字符串后存储，当需要修改对象某个字段是很不方便：

Hash结构可以将对象中的每个字段独立存储，可以针对单个字段做CRUD：

Hash的常见命令

Hash的常见命令有：

• HSET key field value：添加或者修改hash类型key的field的值

• HGET key field：获取一个hash类型key的field的值

• HMSET：批量添加多个hash类型key的field的值

• HMGET：批量获取多个hash类型key的field的值

• HGETALL：获取一个hash类型的key中的所有的field和value

• HKEYS：获取一个hash类型的key中的所有的field

• HVALS：获取一个hash类型的key中的所有的value

• HINCRBY：让一个hash类型key的字段值自增并指定步长

• HSETNX：添加一个hash类型的key的field值，前提是这个field不存在，否则不执行

List类型

Redis中的List类型与Java中的LinkedList类似，可以看做是一个双向链表结构，既可以支持正向检索也支持反向检索。

特征也与LinkedList类似：

• 有序

• 元素可以重复

• 插入和删除快

• 查询速度一般

常用来存储一个有序数据，例如：朋友圈点赞列表，评论列表等。

List类型的常见命令

List的常见命令有：

• LPUSH key element...：向列表左侧插入一个或多个元素

• LPOP key：移除并返回列表左侧的第一个元素，没有则返回nil

• RPUSH key element...：向列表右侧插入一个或多个元素

• RPOP key：移除并返回列表右侧的第一个元素

• LRANGE key star end：返回一段角标范围内的所有元素

• BLPOP和BRPOP：与LPOP和RPOP类似，只不过在没有元素时等待指定时间，而不是直接返回nil

Set类型

Redis的Set结构与Java中HashSet类似，可以看做是一个value为null的HashMap。因为也是一个hash表，因此具备与HashSet类似的特征：

• 无序

• 元素不可重复

• 查找快

• 支持交集、并集、差集等功能

Set类型的常见命令

• SADD key member...：向set中添加一个或多个元素

• SREM key memeber...：移除set中的指定元素

• SCARD key：返回set中元素的个数

• SISMEMBER key member：判断一个元素是否存在于set中

• SMEMBERS：获取set中的所有元素

• SINTER key1 key2...：求key1与key2的交集

• SDIFF key1 key2...：求key1与key2的差集

• SUNION key1 key2...：求key1和key2的并集

SortedSet类型

Redis的SortedSed是一个可排序的set集合，与Java中的TreeSet有些类似，但底层数据结构却差别很大。SortedSet中的每一个元素都带有一个score属性，可以基于score属性对元素排序，底层的实现是一个跳表（SkipList）加hash表。

SortedSet具备下列特性：

• 可排序

• 元素不重复

• 查询速度快

因为SortedSet的可排序特性，经常被用来实现排行榜这样的功能。

SortedSet类型的常见命令

• ZADD key score member：添加一个或多个元素到sorted set，如果已经存在则更新其score值

• ZREM key member：删除sorted set中的一个指定元素

• ZSCORE key member：获取sorted set中的指定元素的score值

• ZRANK key member：获取sorted set中的指定元素的排名

• ZCARD key：获取sorted set中的元素个数

• ZCOUNT key min max：统计score值在给定范围内的所有元素的个数

• ZINCRBY key increment member：让sorted set中的指定元素自增，步长为指定的increment值

• ZRANGE key min max：按照score排序后，获取指定排名范围内的元素

• ZRANGEBYSCORE key min max：按照score排序后，获取指定score范围内的元素

• ZDIFF、ZINTER、ZUNION：求差集、交集、并集

注意：所有的排名默认都是升序，如果要降序则在命令的Z后面添加REV即可如（ZREVRANGE key min max）

SpringDataRedis

SpringDataRedis快速入门

SpringDataRedis的序列化方式

StringRedisTemplate

缓存更新策略

缓存更新策略的最佳实践：

1. 低一致性需求：使用Redis自带的内存淘汰机制

2. 高一致性需求：主动更新，并以超时剔除作为兜底方案

   • 读操作：

     • 缓存命中则直接返回

     • 缓存未命中则查询数据库，并写入缓存，设定超时时间

   • 写操作：

     • 先写数据库，然后再删除缓存

     • 要确保数据库与缓存操作的原子性

缓存穿透解决方案

缓存穿透总结

缓存雪崩解决方案

缓存击穿解决方案

互斥锁示例：

逻辑过期示例：

基于Redis的分布式锁

实现分布式锁时需要实现的两个基本方法：

• 获取锁：

  • 互斥：确保只能有一个线程获取锁

  • 非阻塞：尝试一次，成功返回true，失败返回false

  # 添加锁，NX是互斥，EX是设置超时时间
  SET lock thread1 NX EX 10

• 释放锁：

  • 手动释放

  • 超时释放：获取锁时添加一个超时时间

  # 释放锁 删除即可
  DEL key

流程：

分布式锁误删问题：

解决分布式锁误删问题流程：

Redisson入门

Redisson分布式锁原理

总结

Redisson分布式锁原理：

• 可重入：利用hash结构记录线程id和重入次数。

• 可重试：利用信号量和PubSub功能实现等待，唤醒，获取锁失败的重试机制。

• 超时续约：利用watchDog，每隔一段时间（releaseTime / 3），重置超时时间。

Redis消息队列

基于Stream的消息队列——消费者组

消费者组（Consumer Group）：将多个消费者划分到一个组中，监听同一个队列。具备下列特点。

创建消费者组：

XGROUP CREATE key groupName ID [MKSTREAM]

• key：队列名称

• groupName：消费者组名称

• ID：其实ID标识，￥代表队列中最后一个消息，0则代表队列中第一个消息

• MKSTREAM：队列不存在时自动创建队列

其他常见命令：

# 删除指定的消费者组
XGROUP DESTORY key groupName
# 给指定的消费者组添加消费者
XGROUP CREATECONSUMER key groupname consumername
# 删除消费者组中的指定消费者
XGROUP DELCONSUMER key groupname consumername

从消费者组读取信息：

XREADGROUP GROUP group consumer [COUNT count] [BLOCK milliseconds] [NOACK] STREAME key [key ...] ID [ID ...]

• group：消费组名称

• consumer：消费者名称，如果消费者不存在，会自动创建一个消费者

• count：本次查询的最大数量

• BLOCK milliseconds：当没有消息时最长等待时间

• NOACK：无需手动ACK，获取到消息后自动确认

• STREAMS key：指定队列名称

• ID：获取消息的起始ID：

  • “>”：从下一个未消费的消息开始

  • 其他：根据指定id从pending-list中获取已消费但未确认的消息，例如0，是从pending-list中的第一个消息开始

总结

STREAM类型消息队列的XREADGROUP命令特点：

• 消息可回溯

• 可以多消费者争抢消息，加快消费速度

• 可以阻塞读取

• 没有消息漏读的风险

• 有消息确认机制，保证消息至少被消费一次

HyperLogLog用法

前提需要搞懂的两个概念：

• UV：全称Unique Visitor，也叫独立访客量，是指通过互联网访问、浏览这个网页的自然人。1天内同一个用户多次访问该网站，只记录1次。

• PV：全称Page View，也叫页面访问量或点击量，用户每访问网站的一个页面，记录1次PV，用户多次打开页面，则记录多次PV。往往用来衡量网站的流量。

UV统计在服务端做会比较麻烦，因为要判断该用户是否已经统计过了，需要将统计过的用户信息保存。但是如果每个访问的用户都保存到Redis中，数据量会非常庞大。

Hyperloglog(HLL)是从Loglog算法派生的概率算法，用于确定非常大的集合的基数，而不需要存储其所有值。

Redis中的HLL是基于string结构实现的，单个HLL的内存永远小于16kb，相对于把所有数据都存入reids，内存占用已经非常低了。作为代价，其测量结果是概率性的，有小于0.81%的误差。不过对于UV统计来说，这完全可以忽略。

指令：

测试：

插入数据前内存占用情况885728字节：

测试代码：

/**
 * 使用HyperLogLog往redis里插入1000000条数据，查询内存占用情况
 */
@Test
public void testHyperLogLog() {
    String[] testValues = new String[1000];
    int j = 0;
    for (int i = 0; i < 1000000; i++) {
        j = i % 1000;
        testValues[j] = "user_" + i;
        if (j == 999) {
            //发送到Redis
            stringRedisTemplate.opsForHyperLogLog().add("hl1", testValues);
        }
    }
    //统计插入的数量
    Long count = stringRedisTemplate.opsForHyperLogLog().size("hl1");
    System.out.println("count=" + count); //结果是count=997593
}

插入数据后内存占用情况942080字节：

结果是占用内存是非常低的。

Redis哨兵

哨兵的作用

Redis提供了哨兵(Sentinel)机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下：

• 监控：Sentinel会不断检查您的master和slave是否按预期工作

• 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master，当故障实例恢复后也以新的master为主

• 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

服务状态监控

Sentinel基于心跳机制监测服务状态，每隔一秒向集群的每个实例发送ping命令：

• 主观下线：如果某个Sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。

• 客观下线：若超过指定数量(quorum)的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

选举新的master

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

• 首先会判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点。

• 然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举。

• 如果slave-priority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高。

• 最后是判断slave节点的运行id大小，越小优先级越高。

如何实现故障转移

当选中了其中一个slave为新的master后（例如slave1），故障的转移的步骤如下：

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

• sentinel给所有其他slave发送slaverof 192.168.150.101 7002命令，让这些slave成为新master的从节点，开始从新的master上同步数据。

• 最后，sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点。

Redis哨兵总结

Sentinel的三个作用：

• 监控

• 故障转移

• 通知

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

• 每隔一秒发送一次ping命令，如果超过一段时间没有响应则认为是主观下线。

• 如果大多数sentinel都认为实例主观下线，则判定服务下线。

故障转移步骤有哪些？

• 首先选定一个slave作为新的master，执行 slaveof no one

• 然后让所有节点都执行slaveof (新master地址)

• 修改故障节点配置，添加slaveof (新master地址)

多级缓存

传统缓存的问题

传统的缓存策略一般是请求到达Tomcat后，先查询Redis，如果未命中则查询数据库，存在下面的问题：

• 请求要经过Tomcat处理，Tomcat的性能成为整个系统的瓶颈。

• Redis缓存失效时，会对数据库产生冲击。

多级缓存方案

多级缓存就是充分利用请求处理的每个环节，分别添加缓存，减轻Tomcat压力，提升服务器性能。用作缓存的Nginx是业务Nginx，需要部署为集群，再有专门的Nginx用来做反向代理：

本地进程缓存

缓存在日常开发中起着至关重要的作用 ，由于是存储在内存中，数据的读取速度是非常快的，能大量减少对数据库的访问，减少数据库的压力。缓存可以分为两类：

• 分布式缓存，例如Redis：

  • 优点：存储容量更大、可靠性更好、可以在集群间共享。

  • 缺点：访问缓存有网络开销。

  • 场景：缓存数据量较大、可靠性要求较高、需要在集群间共享。

• 进程本地缓存，例如HashMap、GuavaCache：

  • 优点：读取本地内存，没有网络开销，速度更快。

  • 缺点：存储容量有限、可靠性较低、无法共享。

  • 场景：性能要求较高，缓存数据量较小。

缓存同步策略

缓存数据同步的常见方式有三种：

• 设置有效期：给缓存设置有效期，到期后自动删除。再次查询时更新

  • 优势：简单、方便。

  • 缺点：时效性差，缓存过期之前可能不一致。

  • 场景：更新频率较低，时效性要求低的业务。

• 同步双写：在修改数据库的同时，直接修改缓存

  • 优势：时效性强，缓存与数据库强一致。

  • 缺点：有代码侵入，耦合度高。

  • 场景：对一致性、时效性要求较高的缓存数据。

• 异步通知：修改数据库时发送事件通知，相关服务监听到通知后修改缓存数据

  • 优势：低耦合，可以同时通知多个缓存服务。

  • 缺点：时效性一般，可能存在中间不一致状态。

  • 场景：时效性要求一般，有多个服务需要同步。

大多数缓存方案都可以使用异步通知来实现。

基于Canal的异步通知：

Canal简介

Canal，译意为水道/管道/沟渠，canal是阿里巴巴旗下的一款开源项目，基于java开发。基于数据库增量日志解析，提供增量数据订阅&消费。GitHub的地址：GitHub - alibaba/canal: 阿里巴巴 MySQL binlog 增量订阅&消费组件

Canal是基于mysql的主从同步来实现的，MySQL主从同步的原理如下：

• MySQL master将数据变更写入二进制日志(binary log)，其中记录的数据叫做binary log events

• MySQL slave将master的binary log events拷贝到它的中继日志(relay log)

• MySQL slave重放relay log中事件，将数据变更反映它自己的数据

Canal就是把自己伪装成MySQL的一个slave节点，从而监听master的binary log变化。再把得到的变化信息通知给Canal的客户端，进而完成对其它数据库的同步

Reids的最佳实践

优雅的Key结构：

Redis的Key虽然可以自定义，但最好遵循下面的几个最佳实践约定：

• 遵循基本格式：[业务名称]:[数据名]:[id]

• 长度不超过44字节

• 不包含特殊字符

例如：我们的登录业务，保存用户信息，其key是这样的：

优点：

1. 可读性强

2. 避免key冲突

3. 方便管理

4. 更节省内存：key是string类型，底层编码包含int、embstr和raw三种。embstr在小于44字节使用，采用连续内存空间，内存占用更小。raw模式内存空间不是连续的，底层采用了指针指向了一块空间，在这块空间里存储内容。这样一来内存空间不连续，性能肯定会受到一定的影响，还有可能会产生一些内存碎片，所以raw内存占用会比embstr高一点。

BigKey问题

什么是BigKey

BigKey通常以Key的大小和Key中成员的数量来综合判定，例如：

• Key本身的数据量过大：一个String类型的Key，它的值为5MB。

• Key中的成员数过多：一个ZSET类型的Key，它的成员数量为一万个。

• Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有一千个但这些成员的Value(值)总大小为100MB。

推荐值：

• 单个Key的value小于10kb。

• 对于集合类型的key，建议元素数量小于1000。

BigKey的危害

• 网络阻塞

  对BigKey执行读请求时，少量的QPS（Queries-per-second, 每秒查询率）就可能导致带宽使用率被占满，导致Redis实例，乃至所在物理机变慢。

• 数据倾斜

  BigKey所在的Redis实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡。

• Redis阻塞

  对元素较多的hash、list、zset等做运算会耗时较久，使主线程被阻塞。

• CPU压力

  对BigKey的数据序列化和反序列化会导致CPU的使用率飙升，影响Redis实例和本机其它应用。

如何发现BigKey

• redis-cli --bigkeys

  利用redis-cli提供的--bigkeys参数，可以遍历分析所有key，并返回key的整体统计信息与每个数据的Top1的big key

• scan扫描

  自己编程，利用scan扫描Redis中的所有key，利用strlen、hlen等命令判断key的长度（此处不建议使用MEMORY USAGE）

  java代码实现扫描：

  //字符串模式的最大大小
  final static int STR_MAX_LEN = 10 * 1024;
  //哈希模式的最大大小
  final static int HASH_MAX_LEN = 1000;
  
  @Test
  void testScan(){
      int maxLen = 0;
      long len = 0;
      //初始化游标
      String cursor = "0";
      do{
          //扫描并获取一部分key
          ScanResult<String> result = jedis.scan(cursor);
          //记录cursor
          cursor = result.getCutsor();
          List<String> list = result.getResult();
          if(list == null || list.isEmpty()){
              break;
          }
          //遍历
          for(String key : list){
              //判断key的类型
              String type = jedis.type(key);
              switch(type){
                  case "string":
                      len = jedis.strlen(key);
                      maxLen = STR_MAX_LEN;
                      break;
                  case "hash":
                      len = jedis.hlen(key);
                      maxLen = HASH_MAX_LEN;
                      break;
                  case "list":
                      len = jedis.llen(key);
                      maxLen = HASH_MAX_LEN;
                      break;
                  case "set":
                      len = jedis.scard(key);
                      maxLen = HASH_MAX_LEN;
                      break;
                  case "zset":
                      len = jedis.zcard(key);
                      maxLen = HASH_MAX_LEN;
                      break;
                  default:
                      break;
              }
              if(len >= maxLen){
                  System.out.printf("Found big key : %s, type: %s, length or size: %d %n", key, type, len);
              }
          }
      } while(!cursor.equals("0"));
  }

• 第三方工具

  利用第三方工具，如Redis-Rdb-Tools分析RDB快照文件，全面分析内存使用情况

• 网络监控

  自定义工具，监控进出Redis的网络数据，超出预警值时自动告警

如何删除BigKey

BigKey内存占用较多，即便是删除这样的key也需要耗费很长时间，导致Redis主线程阻塞，引发一系列问题。

• redis3.0及以下版本

  如果是集合类型，则遍历BigKey的元素，先逐个删除子元素，最后删除Bigkey

  redis提供了相应的扫描指令：

• redis4.0以后

  redis在4.0后提供了异步删除的命令：unlink

恰当的数据类型

例1：比如存储一个User对象，可以有三种存储方式：

方式一：json字符串

方式二：字段打散

方式三：hash

例2：假如有hash类型的key，其中有100万对field和value，field是自增id，这个key存在什么问题？如何优化？

方案三：拆分为小的hash，将 id / 100 作为key，将id % 100作为field，这样每100个元素为一个Hash

java测试代码：

@Test
void testSmallHash(){
    int hashSize = 100;
    Map<String, String> map = new HashMap<>(hashSize);
    for(int i = 1; i <= 100000; i++){
        int k = (i - 1) / hashSize;
        int v = i % hashSize;
        map.put("key_" + v, "value_" + v);
        if(v == 0){
            jedis.hmset("test:small:hash_" + k, map);
        }
    }
}

Redis批处理操作

MSET

redis提供了很多Mxxx这样的命令，可以实现批量插入数据，例如：

• mset

• hmset

利用mset批量插入10万条数据：

注意：不要在一次批处理中传输太多命令，否则单次命令占用带宽过多，会导致网络阻塞。

@Test
void testMxx(){
    String[] arr = new String[2000];
    int j;
    for(int i = 1; i <= 100000; i++){
        j = (i % 1000) << 1;
        arr[j] = "test:key_" + i;
        arr[j + 1] = "value_" + i;
        if(j == 0){
            jedis.mset(arr);
        }
    }
}

Pipeline

MSET虽然可以批处理，但是却只能操作部分数据类型，因此如果有对复杂数据类型的批处理需要，建议使用Pipeline功能：

@Test
void testPipeline(){
    //创建管道
    Pipeline pipeline = jedis.pipelined();
    
    for(int i =1; i <= 100000; i++){
        //放入命令到管道
        pipeline.set("test:key_" + i, "value_" + i);
        if(i % 1000 == 0){
            //每放入1000条命令，就批量执行
            pipeline.sync();
        }
    }
}

集群下的批处理

如MSET或Pipeline这样的批处理需要在一次请求中携带多条命令，而此时如果Redis是一个集群，那批处理命令的多个key必须落在一个插槽中，否则就会导致执行失败。

持久化配置

RDB持久化：原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化。

AOF持久化：原理是将Reids的操作日志以追加的方式写入文件。

Redis的持久化虽然可以保证数据安全，但也会带来很多额外的开销，因此持久化请遵循下列建议：

1. 用来做缓存的Redis实例尽量不要开启持久化功能。

2. 建议关闭RDB持久化功能，使用AOF持久化。

3. 利用脚本定期在slave节点做RDB，实现数据备份。

4. 设置合理的rewrite阈值，避免频繁的bgrewrite。

5. 配置no-appendfsync-on-rewrite = yes，禁止在rewrite期间做aof，避免因aof引起的阻塞。

部署有关建议：

1. Redis实例的物理机要预留足够内存，应对fork和rewrite。

2. 单个Redis实例内存上限不要太大，例如4G或8G。可以加快fork的速度、减少主从同步、数据迁移压力。

3. 不要与CPU密集型应用部署在一起。

4. 不要与高硬盘负载应用一起部署。例如：数据库、消息队列。

慢查询

慢查询：在Redis执行时耗时超过某个阈值的命令，称为慢查询。

慢查询的阈值可以通过配置指定：

• slowlog-log-slower-than：慢查询阈值，单位是微秒。默认是10000，建议1000

慢查询会被放入慢查询日志中，日志的长度有上限，可以通过配置指定：

• slowlog-max-len：慢查询日志（本质是一个队列）的长度。默认是128，建议1000

  修改这两个配置可以使用：config set命令：

  这种方式是临时生效，重启就会消失。要永久生效需要改配置文件。

查看慢查询日志列表：

• slowlog len：查询慢查询日志长度。

• slowlog get [n]：读取n条慢查询日志。

• slowlog reset：清空慢查询列表。

命令及安全配置

1. Redis一定要设置密码

2. 禁止线上使用下面命令：keys、flushall、flushdb、config set等命令。可以利用rename-command禁用。

3. bind：限制网卡，禁止外网网卡访问。

4. 开启***。

5. 不要使用root账户启动redis。

6. 尽量不使用默认的端口。

内存安全和配置

当redis内存不足时，可能导致key频繁被删除、响应时间变长、QPS不稳定等问题。当内存使用率达到90%以上时就需要我们警惕，并快速定位到内存占用的原因。

数据内存的问题

redis提供了一些命令，可以查看到redis目前的内存分配状态：

• info memory

• memory xxx

内存缓冲区配置

内存缓冲区常见的有三种：

• 复制缓冲区：主从复制的repl_backlog_buf，如果太小可能导致频繁的全量复制，影响性能。通过repl-backlog-size来设置，默认1mb。

• AOF缓冲区：AFO刷盘之前的缓存区域，AOF执行rewrite的缓冲区。无法设置容量上限。

• 客户端缓冲区：分为输入缓冲区和输出缓冲区，输入缓冲区最大1G且不能设置。输出缓冲区可以设置。

集群最佳实践

集群虽然具备高可用特性，能实现自动故障恢复，但是如果使用不当，也会存在一些问题：

1. 集群完整性问题

   在redis的默认配置中，如果发现任意一个插槽不可用，则整个集群都会停止对外服务：

   为了保证高可用特性，这里建议将cluster-require-full-coverage配置为no。

2. 集群带宽问题

   集群节点之间会不断的互相ping来确定集群中其它节点的状态。每次ping携带的信息至少包括：

   • 插槽信息

   • 集群状态信息

   集群中节点越多，集群状态信息数据量也越大，10个节点的相关信息可能达到1kb，此时每次集群互通需要的带宽会非常高。

   解决途径：

   1. 避免大集群，集群节点数不要太多，最好少于1000，如果业务庞大，则建立多个集群。

   2. 避免在单个物理机中运行太多redis实例。

   3. 配置合适的cluster-node-timeout值。

3. 数据倾斜问题

4. 客户端性能问题

5. 命令的集群兼容性问题

6. lua和事务问题

Redis原理篇

Redis数据结构

动态字符串SDS

Redis中保存的key是字符串，value往往是字符串或者字符串的集合。可见字符串是redis中最常用的一种数据结构。

不过redis没有直接使用c语言中的字符串，因为c语言字符串存在很多问题：

• 获取字符串长度需要通过运算。

• 非二进制安全。

• 不可修改

Redis构建了一种新的字符串结构，称为简单动态字符串（Simple Dynamic String），简称SDS。

例如，执行以下命令：

set name 数据

那么redis将在底层创建两个SDS，其中一个是包含“name”的SDS，另一个是包含“数据”的SDS。

Redis是c语言实现的，其中SDS是一个结构体，源码如下：

例如，一个包含字符串“name”的sds结构如下：

SDS之所以叫做动态字符串，是因为它具备动态扩容的能力，例如一个内容为“hi”的SDS：

假如我们要给SDS追加一段字符串，“Amy”，这里首先会申请新内存空间：

• 如果新字符串小于1M，则新空间为扩展后字符串长度的两倍+1；

• 如果新字符串大于1M，则新空间为扩展后字符串长度+1M+1。称为内存预分配。

IntSet

IntSet是redis中set集合的一种实现方式，基于整数数组来实现，并且具备长度可变、有序等特征。

结构如下：

其中的encoding包含三种模式，表示存储的整数大小不同：

为了方便查找，redis会将intset中所有的整数按照升序依次保存在contents数组中，结构如图：

现在，数组中每个数字都在int16_t的范围内，因此采用的编码方式是INTSET_ENC_INT16，每部分占用的字节大小为：

• encoding：4字节

• length：4字节

• contents：2字节 * 3 = 6字节

IntSet升级

现在，假设有一个intset，元素为{5,10,20}，采用的编码是INTSET_ENC_INT16,则每个整数占2字节：

我们向该intset中添加一个数字：50000，这个数字超出了int16_t的范围，intset会自动升级编码方式到合适的大小。

以当前案例来说流程如下：

1. 升级编码为INTSET_ENC_INT32,每个整数占4字节，并按照新的编码方式及元素个数扩容数组。

2. 倒序依次将数组中的元素拷贝到扩容后的正确位置

3. 将待添加的元素放入数组末尾

4. 最后，将intset的encoding属性改为INTSET_ENC_INT32，将length属性改为4

IntSet新增流程

IntSet升级流程

IntSet总结

IntSet可以看做是特殊的整数数组，具备以下特点：

1. Redis会确保IntSet中的元素唯一、有序。

2. 具备类型升级机制，可以节省内存空间。

3. 底层采用二分查找方式来查询。

Dict

Redis是一个键值型（key-value pair）的数据库，可以根据键实现快速的增删改查。而键与值的映射关系正是通过Dict来实现的。

Dict由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）

当我们向Dict添加键值对时，redis首先根据key计算出hash值（h），然后利用 h & sizemask来计算元素应该存储到数组中的哪个索引位置。我们存储k1=v1，假设k1的哈希值h=1，则1 & 3 = 1，因此k1=v1要存储到数组角标1位置。

Dict的扩容

Dict中的HashTable就是数组结合单向链表的实现，当集合中元素较多时，必然导致哈希冲突增多，链表过长，则查询效率会大大降低。

Dict在每次新增键值对时都会检查负载因子（LoadFactor = used / size），满足以下两种情况时会触发哈希表扩容：

• 哈希表的LoadFactor >= 1，并且服务器没有执行BGSAVE或者BGREWRITEAOF等后台进程；

• 哈希表的LoadFactor > 5；

Dict的收缩

Dict除了扩容以外，每次删除元素时，也会对负载因子做检查，当LoadFactor < 0.1时，会做哈希表收缩：

Dict的rehash

不管是扩容还是收缩，必定会创建新的哈希表，导致哈希表的size和sizemask变化，而key的查询与sizemask有关。因此必须对哈希表中的每一个key重新计算索引，插入新的哈希表，这个过程称为rehash。过程是这样的：

1. 计算新hash表的realeSize，值取决于当前要做的是扩容还是收缩：

   • 如果是扩容，则新size为第一个大于等于dict.ht[0].used + 1的2的n次方。

   • 如果是收缩，则新size为第一个大于等于dict.ht[0].used的2的n次方（不得小于4）。

2. 按照新的realeSize申请内存空间，创建dictht，并赋值给dict.ht[1]。

3. 设置dict.rehashidx = 0，标示开始rehash。

4. 将dict.ht[0]中的每一个dictEntry都rehash到dict.ht[1]。

5. 将dict.ht[1]赋值给dict.ht[0]，给dict.ht[1]初始化为空哈希表，释放原来的dict.ht[0]的内存。

Dict的rehash并不是一次性完成的。试想一下，如果Dict中包含数百万的entry，要在一次rehash完成，极有可能导致主线程阻塞。因此Dict的rehash是分多次、渐进式的完成，因此称为渐进式rehash。流程如下：

Dict总结

Dict的结构

• 类似java的HashTable，底层是数组加链表来解决哈希冲突。

• Dict包含两个哈希表，ht[0]平常用，ht[1]用来rehash。

Dict的伸缩

• 当LoadFactor大于5或者LoadFactor大于1并且没有子进程任务时，Dict扩容。

• 当LoadFactor小于0.1时，Dict收缩。

• 扩容大小为第一个大于等于used + 1的2的n次方。

• 收缩大小为第一个大于等于used的2的n次方。

• Dict采用渐进式rehash，每次访问Dict时执行一次rehash。

• rehash时ht[0]只减不增，新增操作只在ht[1]执行，其他操作在两个哈希表。

ZipList

ZipList是一种特殊的“双端链表”，由一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作，并且该操作的时间复杂度为O(1)。

ZipListEntry

ZipList中的Entry并不像普通链表那样记录前后节点的指针，因为记录两个指针要占用16个字节，浪费内存。而是采用了下面的结构：

• previous_entry_length：前一节点的长度，占1个或5个字节。

  • 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值。

  • 如果前一节点的长度大于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据。

• encoding：编码属性，记录content的数据类型（字符串还是整数）以及长度，占用1个、2个或者5个字节。

• contents：负责保存节点的数据，可以是字符串或整数。

Encoding编码

ZipListEntry中的encoding编码分为字符串和整数两种：

• 字符串：如果encoding是以“00”、“01”或者“10”开头，则证明content是字符串。

  例如，我们要保存字符串：“ab”和“bc”

• 整数：如果encoding是以“11”开始，则证明content是整数，且encoding固定只占用1个字节

  例如，一个ZipList中包含两个整数值：“2”和“5”

ZipList的连锁更新问题

ZipList的每个Entry都包含previous_entry_length来记录上一个节点的大小，长度是1个或5个字节：

• 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值。

• 如果前一节点的长度大于等于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据。

现在，假设我们有n个连续的、长度为250~253字节之间的entry，因此entry的previous_entry_length属性用1个字节即可表示，如图所示：

ZipList这种特殊情况下产生的连续多次空间扩展操作称之为连锁更新（Cascade Update）。新增、删除都可能导致连锁更新的发生。

ZipList总结

ZipList特性：

1. 压缩列表的可以看做一种连续内存空间的“双向链表”。它本质上不是一个双向链表，因为列表的节点之间不是通过指针连接，而是记录上一个节点和本节点长度来寻址，内存占用较低。

2. 如果列表数据过多，导致链表过长，可能影响查询性能。

3. 增或删较大数据时可能发生连续更新问题。

QuickList

问题1：ZipList虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低。怎么办？

为了缓解这个问题，我们必须限制ZipList的长度和entry大小。

问题2：但是我们要存储大量数据，超出了ZipList最佳的上限该怎么办？

可以创建多个ZipList来分片存储数据。

问题3：数据拆分后比较分散，不方便管理和查找，这多个ZipList如何建立联系？

redis在3.2版本引入了新的数据结构QuickList，它是一个双端链表，只不过链表中的每个节点都是一个ZipList。

为了避免QuickList中的每个ZipList中entry过多，redis提供了一个配置项：list-max-ziplist-size来限制。

• 如果值为正，则代表ZipList的允许的entry个数的最大值。

• 如果值为负，则代表ZipList的最大内存大小，分5种情况：

  1. -1：每个ZipList的内存占用不能超过4kb。

  2. -2：每个ZipList的内存占用不能超过8kb。

  3. -3：每个ZipList的内存占用不能超过16kb。

  4. -4：每个ZipList的内存占用不能超过32kb。

  5. -5：每个ZipList的内存占用不能超过64kb。

  其默认值为-2：

除了控制ZipList的大小，QuickList还可以对节点的ZipList做压缩。通过配置项list-compress-depth来控制。因为链表一般都是从首尾访问较多，所以首尾是不压缩的。这个参数是控制首尾不压缩的节点个数：

• 0：特殊值，代表不压缩。

• 1：表示QuickList的首尾各有1个节点不压缩，中间节点压缩。

• 2：表示QuickList的首尾各有2个节点不压缩，中间节点压缩。

• 以此类推

默认值：

以下是QuickList的和QuickListNode的结构源码：

QuickList总结

QuickList特点：

• 是一个节点为ZipList的双端链表。

• 节点采用ZipList，解决了传统链表的内存占用问题。

• 控制了ZipList大小，解决连续内存空间申请效率问题。

• 中间节点可以压缩，进一步节省了内存。

SkipList

SkipList(跳表) 首先是链表，但与传统链表相比有几点差异：

• 元素按照升序排列存储。

• 节点可能包含多个指针，指针跨度不同。

SkipList总结

SkipList的特点：

• 跳表是一个双向链表，每个节点都包含score和ele值。

• 节点按照score值排序，score值一样则按照ele字典排序。

• 每个节点都可以包含多层指针，层数是1到32之间的随机数。

• 不同层指针到下一个节点的跨度不同，层级越高，跨度越大。

• 增删改查效率与红黑树基本一致，实现却更简单。

RedisObject

redis中的任意数据类型的键和值都会被封装为一个RedisObject，也叫做Redis对象，源码如下：

Redis的编码方式

redis中会根据存储的数据类型不同，选择不同的编码方式，共包含11种不同类型：

五种数据结构

redis中会根据存储的数据类型不同，选择不同的编码方式。每种数据类型的使用的编码方式如下：

String

String是redis中最常见的数据存储类型：

• 其基本编码方式是RAW，基于简单动态字符串（SDS）实现，存储上限为512mb。

• 如果存储的SDS长度小于44字节，则会采用EMBSTR编码，此时object head与SDS是一段连续空间。申请内存时只需要调用一次内存分配函数，效率更高。

• 如果存储的字符串是整数值，并且大小在LONG_MAX范围内，则会采用INT编码：直接将数据保存在RedisObject的ptr指针位置（刚好8字节），不再需要SDS了。

List

redis的List类型可以从首、尾操作列表中的元素：

哪一个数据结构能满足上述特征？

• LinkedList：普通链表，可以从双端访问，内存占用较高，内存碎片较多。

• ZipList：压缩列表，可以从双端访问，内存占用低，存储上限低。

• QuickList：LinkedList + ZipList，可以从双端访问，内存占用较低，包含多个ZipList，存储上限高。

redis的list结构类似一个双端链表，可以从首、尾操作列表中的元素：

• 在3.2版本之前，redis采用ZipList和LinkedList来实现List，当元素数量小于512并且元素大小小于64字节时采用ZipList编码，超过则采用LinkedList编码。

• 在3.2版本之后，redis统一采用QuickList来实现List：

List数据结构：

Set

Set是redis中的单列集合，满足下列特点：

• 不保证有序性。

• 保证元素唯一（可以判断元素是否存在）。

• 求交集、并集、差集。

  可以看出，Set对查询元素的效率要求非常高，什么样的数据结构可以满足？

• HashTable，也就是redis中的Dict，不过Dict是双列集合（可以存键值对）。

Set是redis中的集合，不一定确保元素有序，可以满足元素唯一，查询效率要求极高。

• 为了查询效率和唯一性，set采用HT编码（Dict）。Dict中的key用来存储元素，value统一为null。

• 当存储的所有数据都是整数，并且元素数量不超过set-max-intset-entries时，set会采用IntSet编码，以节省内存。

Set数据结构：

ZSet

ZSet也就是SortedSet，其中每一个元素都需要指定一个score值和member值：

• 可以根据score值排序后。

• member必须唯一。

• 可以根据member查询分数。

因此，zset底层数据结构必须满足键值存储、键必须唯一、可排序这几个需求。哪种编码结构可以满足？

• SkipList：可以排序，并且可以同时存储score和ele值（member）

• HT（Dict）：可以键值存储，并且可以根据key找value。

当元素数量不多时，HT和SkipList的优势不明显，而且更耗内存。因此zset还会采用ZipList结构来节省内存，不过需要同时满足两个条件：

1. 元素数量小于zset_max_ziplist_entries，默认值128。

2. 每个元素都小于zset_max_ziplist_value字节，默认值64。

ziplist本身没有排序功能，而且没有键值对的概念，因此需要有zset通过编码实现：

• ZipList是连续内存，因此score和element是紧挨在一起的连个entry，element在前，score在后。

• score越小越接近队首，score越大越接近队尾，按照score值升序排列。

Hash

Hash结构与redis中的ZSet非常类似：

• 都是键值存储。

• 都需要根据键获取值。

• 键必须唯一。

区别如下：

• zset的键是member，值是score；hash的键和值都是任意值。

• zset要根据score排序；hash则无需排序。

因此，Hash底层采用的编码与Zset也基本一致，只需要把排序有关的SkipList去掉即可；

• Hash结构默认采用ZipList编码，用以节省内存。ZipList中相邻的两个entry分别保存field和value。

• 当数据量较大时，Hash结构会转为HT编码，也就是Dict，触发条件有两个：

  1. ZipList中的元素数量超过了hash-max-ziplist-entries（默认512字节）。

  2. ZipList中的任意entry大小超过了hash-max-ziplist-value（默认64字节）。

Redis网络模型

用户空间和内核空间

为了避免用户应用导致冲突甚至内核崩溃，用户应用与内核是分离的：

• 进程的寻址空间会划分为两部分：内核空间、用户空间。

• 用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问。

• 内核空间可以执行特权命令（Ring0），调用一切系统资源。

Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：

• 写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备。

• 读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区。

IO模型

阻塞IO

顾名思义，阻塞IO就是两个阶段都必须阻塞等待：

可以看到，阻塞IO模型中，用户进程在俩个阶段都是阻塞状态。

非阻塞IO

非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

IO多路复用

无论是阻塞IO还是非阻塞IO，用户应用在一阶段都需要调用recvfrom来获取数据，差别在于无数据时的处理方案：

• 如果调用recvfrom时，恰好没有数据，阻塞IO会使进程阻塞，非阻塞IO使CPU空转，都不能充分发挥CPU的作用。

• 如果调用recvfrom时，恰好有数据，则用户进程可以直接进入第二阶段，读取并处理数据。

比如服务端处理客户端Socket请求时，在单线程情况下，只能依次处理每一个socket，如果正在处理的socket恰好未就绪（数据不可读或不可写），线程就会被阻塞，所有其他客户端socket都必须等待，性能自然会很差。

文件描述符（File Descriptor）：简称FD，是一个从0开始递增的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。

IO多路复用：是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

不过监听FD的方式、通知的方式又有多种实现，常见的有：

• select

• poll

• epoll

差异：

• select和poll只会通知用户进程有FD就绪，但不确定具体是哪个FD，需要用户进程逐个遍历FD来确认。

• epoll则会在通知用户进程FD就绪的同时，把已就绪的FD写入用户空间。

IO多路复用-select

select是Linux中最早的I/O多路复用实现方案：

IO多路复用-poll

poll模式对select模式做了简单改进，但性能提升不明显，部分关键代码如下：

IO多路复用-epoll

IO多路复用模式总结

select模式存在的三个问题：

• 能监听的FD最大不超过1024。

• 每次select都需要把所有要监听的FD都拷贝到内核空间。

• 每次都要遍历所有FD来判断就绪状态。

poll模式的问题：

• poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降。

epoll模式中如何解决这些问题的？

• 基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高，性能不会随监听的FD数量增多而下降。

• 每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epoll_wait无需传递任何参数，无需重复拷贝FD到内核空间。

• 内核会将就绪的FD直接拷贝到用户空间的指定位置，用户进程无需遍历所有FD就能知道就绪的FD是谁。

IO多路复用-事件通知机制

当FD有数据可读时，我们调用epoll_wait就可以得到通知。但是事件通知的模式有两种：

• LevelTriggered：简称LT。当FD有数据可读时，会重复通知多次，直至数据处理完成。是Epoll的默认模式。

• EdgeTriggered：简称ET。当FD有数据可读时，只会被通知一次，不管数据是否处理完成。

IO多路复用-web服务流程

信号驱动IO

信号驱动IO是与内核简历SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其他业务，无需阻塞等待。

当有大量IO操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出。而且内核空间与用户空间的频繁信号交互性能也较低。

异步IO

异步IO的整个过程都是非阻塞的，用户进程调用玩异步API后就可以去做其他事情，内核等待数据就绪并拷贝到用户空间后才会递交信号，通知用户进程。

可以看到，异步IO模型中，用户进程在两个阶段都是非阻塞状态。

同步和异步

IO操作是同步还是异步，关键看数据在内核空间与用户空间的拷贝过程（数据读写的IO操作），也就是阶段二是同步还是异步：

常见面试题

1.Redis到底是单线程还是多线程？

• 如果仅仅聊redis的核心业务部分（命令处理），答案是单线程。

• 如果是聊整个redis，那么答案就是多线程。

在redis版本迭代过程中，在两个重要的时间节点上引入了多线程的支持：

• Redis v4.0：引入多线程异步处理一些耗时较长的任务，例如异步删除命令unlink。

• Redis v6.0：在核心网络模型中引入多线程，进一步提高对于多核CPU的利用率。

2.为什么Redis要选择单线程？

• 抛开持久化不谈，redis是纯内存操作，执行速度非常快，它的性能瓶颈是网路延迟而不是执行速度，因此多线程并不会带来巨大的性能提升。

• 多线程会导致过多的上下文切换，带来不必要的开销。

• 引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣。

Redis网络模型结构

单线程情况下：

Redis 6.0版本中引入了多线程，目的是为了提高IO读写效率。因此在解析客户端命令、写响应结果时采用了多线程。核心的命令执行、IO多路复用模块依然是由主线程执行。

Redis通信协议

RESP协议

Redis是一个CS架构的软件，通信一般分两步（不包括pipeline和PubSub）：

1. 客户端（client）向服务端（server）发送一条命令。

2. 服务端解析并执行命令，返回响应结果给客户端。

因此客户端发送命令的格式、服务端响应结果的格式必须有一个规范，这个规范就是通信协议。

而在Redis中采用的是RESP（Redis Serialization Protocol）协议：

• Redis 1.2版本引入了RESP协议。

• Redis 2.0版本中成为与Redis服务端通信的标准，称为RESP2。

• Redis 6.0版本中，从RESP2升级到了RESP3协议，增加了更多数据类型并且支持6.0的新特性--客户端缓存。

但目前，默认使用的依然是RESP2协议。

RESP协议-数据类型

Redis内存回收

Redis之所以性能强，最主要的原因就是基于内存存储。然而单节点的redis其内存大小不宜过大，会影响持久化或主从同步性能。

我们可以通过修改配置文件来设置redis的最大内存。

当内存使用达到上限时，就无法存储更多数据了。

过期策略

在redis中可以通过expire命令给redis的key设置TTL（存活时间）：

可以发现，当key的TTL到期以后，再次访问name返回的是nil，说明这个key已经不存在了，对应的内存也得到释放。

从而起到内存回收的目的。

过期策略-DB结构

redis本身是一个典型的key-value内存存储数据库，因此所有的key、value都保存在之前学习过的Dict结构中。不过在其database结构体中，有两个Dict：一个用来记录key-value；另一个用来记录key-TTL。

过期策略-惰性删除

惰性删除：顾名思义并不是在TTL到期后就立刻删除，而是在访问一个key的时候，检查该key的存活时间，如果已经过期才执行删除。

过期策略-周期删除

周期删除：顾名思义是通过一个定时任务，周期性的抽样部分过期的key，然后执行删除。执行周期有两种：

• Redis会设置一个定时任务serverCron()，按照server.hz的频率来执行过期key清理，模式为SLOW。

• Redis的每个事件循环前会调用beforeSleep()函数，执行过期key清理，模式为FAST。

SLOW模式规则：

1. 执行频率受server.hz影响，默认为10，即每秒执行10次，每个执行周期100ms。

2. 执行清理耗时不超过一次执行周期的25%。

3. 逐个遍历db，逐个遍历db中的bucket，抽取20个key判断是否过期。

4. 如果没达到时间上限（25ms）并且过期key比例大于10%，在进行一次抽样，否则结束。

FAST模式规则（过期key比例小于10%不执行）：

1. 执行频率受beforeSleep()调用频率影响，但两次FAST模式间隔不低于2ms。

2. 执行清理耗时不超过1ms。

3. 逐个遍历db，逐个遍历db中的bucket，抽取20个key判断是否过期。

4. 如果没达到时间上限（1ms）并且过期key比例大于10%，再进行一次抽样，否则结束。

过期策略总结

RedisKey的TTL记录方式：

• 在RedisDB中通过一个Dict记录每个Key的TTL时间。

过期key的删除策略：

• 惰性清理：每次查找key时判断是否过期，如果过期则删除。

• 定期清理：定期抽样部分key，判断是否过期，如果过期则删除。

定期清理的两种模式：

• SLOW模式执行频率默认为10，每次不超过25ms。

• FAST模式执行频率不固定，但两次间隔不低于2ms，每次耗时不超过1ms。

淘汰策略

内存淘汰：就是当Redis内存使用达到设置的阈值时，redis主动挑选部分key删除以释放更多内存的流程。

redis会处理客户端命令的方法processCommand()中尝试做内存淘汰：

Redis支持8种不同策略来选择要删除的key：

• 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，基于LFU算法进行淘汰。

比较容易混淆的有两个：

• LRU（Least Recently Used），最少最近使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。

• LFU（Least Frequently Used），最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。

Redis的数据都会被封装为RedisObject结构：

LFU的访问次数之所以叫做逻辑访问次数，是因为并不是每次key被访问都计数，而是通过运算：

1. 生成0~1之间的随机数R。

2. 计算 1/(旧次数 * lfu_log_factor + 1)，记录为P，lfu_log_factor默认为10。

3. 如果R < P，则计数器 + 1，且最大不超过255。

4. 访问次数会随时间衰减，距离上一次访问时间每隔lfu_decay_time分钟（默认1），计数器 - 1。

#Redis##redis高频面试题##面试##容器##后端#