Redis

一、Redis简介
- 1.1. 适用场景
- 1.2. 常用数据类型
- 1.3. 单点Redis缺陷
二、持久化机制（解决数据丢失）
- 2.1. RDB
- - 2.1.1. RDB优缺点
- 2.2. AOF
- - 2.2.1. AOF配置
  - 2.2.2. AOF优缺点
三、Redis集群
- 3.1. 主从（解决并发读）
- - 3.1.1. 主从数据同步原理
  - 3.1.1. 选举机制
- 3.2. 哨兵（解决单点故障）
- - 3.2.1. 监控原理
  - 3.2.2. 故障恢复原理
- 3.3. 分片集群（解决高并发读与高可用）
- - 3.3.1. 分片策略
  - 3.3.2. 插槽原理
  - 3.3.3. 故障转移
  - 3.3.4. 动态扩展
四、分布式锁
- 4.1. Redis分布式锁
- - 4.1.1. SETNX命令锁
  - 4.1.2. Lua脚本锁
  - 4.1.3. RedLock算法锁
- 4.2. Redission框架
- - 4.2.1. 基于Redis的分布式锁
  - 4.2.2. 基于RedLock算法的分布式锁
- 4.3. Watchdog机制
五、Redis策略
- 5.1. 数据过期策略（Key过期）
- - 5.1.1. 定时删除策略
  - 5.1.2. 惰性刪除策略
  - 5.1.3. 定期删除策略
  - 5.1.4. 延迟过期策略
- 5.2. 数据淘汰策略（内存不足）
六、Redis缓存问题
- 6.1. 缓存穿透
- - 6.1.1. 缓存空对象
  - 6.1.1. 布隆过滤器
- 6.2. 缓存雪崩
- 6.3. 缓存击穿
- - 6.3.1. 互斥锁方案
  - 6.3.2. 逻辑过期方案

一、Redis简介

Redis：基于内存的键值存储系统，通常用作高性能的数据库、缓存和消息队列代理，是互联网广泛应用的存储中间件

特点：基于内存存储，读写性能高

Redis与MySQL区别

Redis以键值对形式存储，MySQL以表格形式存储
Redis存储在内存，MySQL存储在磁盘
Redis存储高效，MySQL存储安全
锁的侧重点不同

1.1. 适用场景

作为一款高性能的数据库，Redis适用的场景很多

缓存：适合存储访问量大的热点数据（热销商品、热点资讯、热点文章等）。
消息队列：构建简单而高效的消息队列系统，适合处理大量实时消息，支持多个消费者并发处理消息。
会话存储：对于用户会话记录等重要性较低的数据进行高效存储。
延迟队列：使用zset的score来存储时间戳，对时间进行排序，当score小于等于预设值，则发送消息。

1.2. 常用数据类型

Redis有5种基本常用数据类型：

字符串 String
哈希 hash
列表 list
集合 set
有序集合 sorted set / zset

在这里插入图片描述

字符串（String）：字符串类型，最简单的数据类型。
哈希（Hash）：散列，类似于Java的HashMap结构。
列表（list）：按照插入顺序排序，可重复，类似Java的LinkedList。
集合（set）：无序集合，不可重复，类似Java的HashSet。
有序集合（sorted set / zset）：集合中每个元素关联一个分值（score），根据分值升序排序，不可重复。

1.3. 单点Redis缺陷

单点（单节点）

单点Redis存在的主要缺陷

数据丢失：服务器重启，内存的数据可能丢失。
单点故障：如果Redis宕机，整个服务不可用，系统可用性大幅降低。
有限并发：Redis为单线程模型，每次仅能处理一个命令，虽然高效，但并发量可能成为系统性能的瓶颈。
有限存储：内存存储模式受限于物理服务器内存的限制，数据量剧增，影响系统性能。

在这里插入图片描述

二、持久化机制（解决数据丢失）

Redis中的持久化机制有两种

在Redis4.0支持RDB与AOF混合使用

2.1. RDB

RDB：Redis默认持久化机制，将内存中的数据以二进制格式快照的方式保存到硬盘的RDB文件中。

触发机制

执行指令，或者基于指定（默认）的时间间隔，指定修改次数触发。

执行save指令
执行bgsave指令
Redis停机
触发RDB条件

1. save指令：输入save，立即执行一次RDB

save指令会导致主进程执行RDB，其他所有指令会被阻塞，适用于数据迁移。

在这里插入图片描述

2. bgsave指令：输入bgsave，开启异步RDB

指令执行后会开启异步的RDB，与主进程互不干扰
在这里插入图片描述

3. Redis停机：在Redis停机之前，会自动执行一次save指令，实现持久化机制

4. 触发RDB条件：Redis的conf文件中可以修改RDB触发条件

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000

2.1.1. RDB优缺点

优点

RDB适用于备份和灾难恢复。
将大规模数据集压缩成很小的快照。
加载速度比AOF快。

缺点

RDB是定期生成快照，如果Redis宕机，最后一次快照的数据将会丢失。
数据量大时，生成RDB可能会使Redis停止服务一段时间。
对于频繁执行写操作，RDB可能导致较高的数据丢失。

2.2. AOF

AOF：以日志的形式记录每个操作，将操作追加到文件末尾，类似事务日志

在这里插入图片描述

触发机制

可以配置为每个写操作或每秒触发一次

2.2.1. AOF配置

Redis中，AOF默认是关闭状态，需要手动修改conf配置文件来开启AOF

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

AOF的指令记录评率也可以通过conf文件配置

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

AOF文件重写

AOF会记录每一次操作，同时会出现一个问题：如果对同一个key多次写操作，存储量变大，造成资源浪费，只有最后一次写操作才会有意义。

通过bgrewriteaof指令，可以让AOF文件执行重写功能，达到存储最后一次写操作。
在这里插入图片描述

配置自动重写

在redis.conf中可以配置阈值，使Redis在触发阈值时自动重写AOF文件

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb

2.2.2. AOF优缺点

优点

以追加的方式记录每个写操作，最大程度上避免数据丢失。
AOF文件是一个完整的操作日志，可以通过重放日志来修复数据。
可以选择不同策略：fsync（每次写入都同步到磁盘）或每秒同步一次

缺点

AOF文件通常比RDB文件大
AOF恢复速度可能比RDB慢，特别是AOF文件很大的情况下

三、Redis集群

3.1. 主从（解决并发读）

主从：主从集群，提高Redis的可用性和扩展性

一主多从：主负责读写，从复制主数据。
在这里插入图片描述
主从集群特点：

主节点负责读写，从节点复制主节点的数据。
从节点只能进行读操作。
主节点宕机，会在从节点中选举出一个新的主节点。

3.1.1. 主从数据同步原理

主从第一次建立连接时，会自动执行全量同步，将主节点（master）的所有数据都拷贝给从节点（slave）
在这里插入图片描述

主从集群数据同步具体实现流程

新增slave集群，并发送增量同步请求
master节点判断replid，如不一致，拒绝请求，并把完整数据生成RDB，发送到slave
slave清空本地数据并加载master传来的RDB
master将RDB期间执行的指令记录在repl_baklog，并持续将log中的指令发送到slave
slave执行接收的指令，保持与master的同步

流程理解

最初的slave也是一个全新的集群（master），有自己的replid和offset，当它变成slave，与master建立起连接，发送自己的replid与offset到master。

这时master会对传来的replid和offset进行判断，如果和自己的不同，则说明它是一个全新的集群，就会将自己的replid和offset发送给新集群，并对其进行全量同步，然后新集群会将replid保存到本地，这样slave与master的replid一致了。

因此，master判断一个节点是否是第一次同步，判断的是replid是否一致。

知识点补充

Replication id：简写为replid，数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid。

offset： 偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master，说明slave数据落后于master，需要更新。

全量同步： 主从第一次连接所做的同步就是全量同步。master将完整数据生成RDB，发送到slave，后续指令则记录在repl_baklog，逐个发送给每个slave。

增量同步： 在现有的基础上，更新slave与master存在差异的部分数据，如下图所示

在这里插入图片描述

3.1.1. 选举机制

当主从集群的主节点故障（宕机）时，从节点可以自动选举出一个新的主节点。

从节点根据优先级、复制偏移量等因素选择新的主节点，当主节点恢复正常后，它将变为从节点，并同步新主节点的数据。

3.2. 哨兵（解决单点故障）

哨兵（Sentinel）：哨兵集群，通过监控和自动故障转移来保证Redis的可靠性

组成

哨兵集群由多个哨兵节点和多个Redis实例组成。

在这里插入图片描述

职责

监控：sentinel节点负责监控master与slave的健康状态并进行故障检测和转移。
自动故障恢复：如果master故障，Sentinel会将一个slave提升为master，当故障的主节点恢复后，还是以新的master为主。
通知：sentinel充当客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给redis的客户端。

3.2.1. 监控原理

哨兵存在意义就是为了监控Redis主从集群的运行情况，在master或slave宕机的时候，进行故障的恢复。

sentinel定期向master-slave发送心跳信号（ping），如果master-slave在指定时间没有响应信号，则代表当前sentinel认为该master主观下线。
当指定数量（一般过半）的sentinel都认为该实例主观下线，则该实例就被确认为客观下线，这时候sentinel就会选择一个从节点作为新的主节点，并将其切换到主节点状态。
故障转移过程中，sentinel会通知客户端新的master的地址，以确保客户端可以重连。

3.2.2. 故障恢复原理

一旦发现master故障，Sentinel需要在slave中选择一个相近的作为新的master。

master选举流程

sentinel会判断slave节点与master节点断开时间的长短，如果超过指定值（down-after-milliseconds * 10），则会排除该slave节点。
再判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举。
如果slave-prority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高。
最后是判断slave节点的运行id大小，越小优先级越高。

master切换流程

sentinel给备选的slave节点发送slaveof no one指令，让其成为新的master。
sentinel给其他的slave发送指令：slaveof 192.168.150.101 7002（master地址），让这些slave成为新master的从节点，并开始从master同步数据。
sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新master的从节点。

在这里插入图片描述

3.3. 分片集群（解决高并发读与高可用）

主从、哨兵解决了redis的高并发写，单点故障，但是还有两个常见的问题并没有解决：

高并发读
海量数据存储

这时就用到了一个新的集群：分片集群（cluster）

在这里插入图片描述

分片特征

在一个分片集群中，允许有多个master的存在，每个master存储不同的数据，且每个master下可以有多个slave节点；
master之间也会通过ping检测彼此健康状态；
客户端访问任意的集群，最终都会被转发到正确节点。

3.3.1. 分片策略

cluster的存在意义是为了解决单点reids的存储与并发问题，因此需要把数据分散到各个master，类似数据库的分库。

cluster的分片策略有如下几种种：

哈希分片：根据键的哈希值将数据分配到不同节点，相同的键始终映射到同一个节点。
范围分片：通过分区键是否在范围内来进行分区，例如：存储区一分区键为1-1000，那么1-1000的数据就存储在区一。
一致性hash分区：redis的cluster集群没有采用一致性的哈希方案，它采用的是数据分片中的哈希槽来对数据进行存储与读取的。

3.3.2. 插槽原理

哈希槽：redis集群会预先分好16384（0-16383）个插槽（hash slot），当需要在redis集群放置一个key-value时，会根据CRC16算法得到相应的值，再决定将这个key放置在哪个插槽中。

假设主节点的数量为3，将redis集群的16384个槽位按自定义的规则区分配这三个节点，每个master复制一份槽位。

在这里插入图片描述

节点1槽位：0 - 5460

节点2槽位：5461 - 10922

节点3槽位：10923 - 16383

数据中的key与插槽绑定，而不是与节点，redis会根据key的有效部分计算插槽值。

注意！！！

slave是没有槽位的，只有master才会有槽位。

3.3.3. 故障转移

cluster也相应的有自己的故障处理机制

当一个master节点宕机或下线，cluster会使用复制机制保证数据的安全，sentinel会复制主节点的数据，当master故障，slave会被提升为新的master，故障的master恢复后，变为新的slave，并同步新的master数据。

正常三节点cluster
7001、7002、7003都是master，现在让7002宕机

在这里插入图片描述
疑似宕机

在这里插入图片描述
确定下线后自动提升一个slave为新的master

在这里插入图片描述
当7002再次启动，自动变为新的slave

在这里插入图片描述

3.3.4. 动态扩展

cluster允许动态添加或删除节点

添加：对现有数据进行重新分片和迁移，确保数据均分到新节点。
删除：将该节点的数据重新分配给其他节点。

四、分布式锁

什么是分布式锁?

分布式环境中，由于多个进程或节点之间的通信延迟、网络分区等因素影响，传统的单机锁机制已经无法满足分布式系统的需求，因此，分布式锁通常基于分布式存储系统或数据库等实现。

分布式锁核心：多个进程或节点同时访问共享的资源时，分布式锁能够确保只有一个进程或节点获取到锁（所有人用同一把锁），锁住线程，让程序串行执行，避免竞争冲突。

分布式锁的分类

MySQL锁
Redis锁
ZooKeeper锁

MySQL锁：在数据库的层面，使用数据库的事务和行级锁来实现并发控制。
Redis锁与ZooKeeper锁：分布式储存系统层面：基本都基于它们的原子性操作和特性实现

注：
三种锁各有优缺，分布式系统存在CAP情况，任何一个分布式系统最多满足两种特效，无法同时满足三种特性。

4.1. Redis分布式锁

Redis分布式锁：利用redis提供的原子操作和特性来实现的一种分布式锁机制，用于解决多个线程或者线程间的互斥访问问题。

Redis锁核心依旧是让多个线程使用同一把锁，防止资源共抢的情况。
Redis锁核心思路

获取锁
- 互斥特性：确保只能有一个线程获取锁
- 非阻塞特性：尝试一次，成功返回true，失败返回false
释放锁
- 手动释放：手动释放锁
- 超时释放：添加锁的过期时间，到期自动释放

在这里插入图片描述

4.1.1. SETNX命令锁

SETNX命令锁：利用SETNX命令的原子性，通过判断返回值来确定是否成功获取到锁。

使用SETNX命令来设置一个键值对，如果键不存在，则设置成功，并返回1；如果已经存在，则设置失败，并返回0.

简单来说就是：插入key成功，表示获得锁，返回1；如果有人插入成功了，其他人则不能再次插入，必须等前面的人释放锁后才可继续插入，这时失败会返回0。

获取锁

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

# 添加锁,利用setnx的互斥特性
SETNX lock thread1

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

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

释放锁

手动释放

# 释放锁,删除即可
DEL Key

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

# 添加锁过期时间,避免服务宕机引起的死锁
EXPIRE lock 10

在Java中创建setnx锁

import org.springframework.data.redis.core.StringRedisTemplate;
import java.util.concurrent.TimeUnit;

/**
 * 创建setnx锁
 */
public class RedisSetNxLock {

    //定义锁的名称
    private final String name;
    private final StringRedisTemplate stringRedisTemplate;

    public RedisSetNxLock(String name, StringRedisTemplate stringRedisTemplate) {
        this.name = name;
        this.stringRedisTemplate = stringRedisTemplate;
    }

    //定义当前key的前缀,大小写快捷键ctrl+shift+u
    private static  final String KEY_PREFIX="lock:";

    /**
     * 获取锁
     *
     * @param timeoutsec key的过期时间
     * @return true表示拿到锁，false表示没有拿到锁
     */
    public boolean tryLock(Long timeoutsec) {
        //2.获取当前线程的id作为value值，保证唯一性
        long threadId = Thread.currentThread().getId();

        /**
         * 1.获取锁
         * setIfAbsent(K key, V value, long timeout, TimeUnit unit)
         *
         key –参数1表示redis中的key
         value – 参数2表示redis中存储的值
         timeout – 参数3表示key的过期时间
         unit – 参数4表示时间单位
         */
        Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, threadId + "", timeoutsec, TimeUnit.MINUTES);
        /**
         * 这个是为了防止类型的拆箱，如果返回值为null的话，boolean类型会报错
         * 意思：如果相等于则返回true,不想等于返回false,如果flag=null的话，也是返回false;
         */
        return Boolean.TRUE.equals(flag);
    }

    /**
     * 释放锁
     *
     */
    public void unLock() {
        //通过手动释放锁
        stringRedisTemplate.delete(KEY_PREFIX+name);
    }
}

redis锁的原子性问题

现在线程1持有锁，执行业务逻辑过程中，准备删锁，而且已经走到了条件判断的过程中，但此时他的锁到期了，也会接着执行，但此时线程2已经进来了，而恰巧线程1的卡顿结束后，执行删除锁，这样的话相当于条件判断并没有起到作用，这就是redis锁的原子性问题。

这种情况可以通过Lua脚本锁来解决。

4.1.2. Lua脚本锁

Lua脚本锁：用lua去编写多条redis语句，确保多条命令执行时的原子性。

使用Redis的EVAL命令执行Lua脚本，利用GETSET命令的原子性，对比当前值和期望值来获取锁，并设置新的值。

Lua脚本：一种轻量级的嵌入式脚本语言，常用于扩展应用程序的逻辑和功能。

4.1.3. RedLock算法锁

RedLock算法锁：Redlock在redis实例集群上实现的一种分布式锁算法，使用多把锁来防止单节点redis分布式锁宕机的问题。

Redlock算法的思路

使用N个独立且互不相干的集群节点（通常为主从架构）。
获取锁时，客户端会向这N个节点发起请求，在多数节点上获取锁，当获取到多数节点的锁后，即被认为成功获取锁。
释放锁时，客户端会向所有节点发送解锁请求，只有在大多数节点上成功解锁，锁才会被释放。

所以，Redlock算法与传统SETNX的区别是：在多数节点成功获取或解锁后才被认为有效，即使小部分的节点宕机，也不会影响到其他分布式锁的可用性。

4.2. Redission框架

SETNX锁的缺陷

不支持重入：SETNX锁是基于键的操作，不支持同一个客户端对同一个锁的重入，容易出现死锁和资源浪费的情况。

重入问题是指获得锁的线程可以再次进入到相同的锁代码中，可重入锁的意义在于防止死锁。

比如HashTable这样的代码，它的方法都是使用synchronized修饰的：假设它在一个方法内，调用另一个方法，如果此时它不可重入，就死锁了，所以可重入锁的主要意义是防止死锁，synchronized和lock锁都是可重入的。

没有超时释放机制：SETNX锁是没有内置的超时机制的，即如果一个用户得到锁，在操作过程中宕机了，其他客户端就无法获取锁了，又导致了死锁，所以每次使用SETNX锁时，都需要自己手动设置锁过期时间。
锁释放异常：如果用户已经获取锁，在释放锁前异常宕机，其他客户端无法判断锁是否释放，导致其他线程阻塞。

例如：redis提供了master-slave，向集群写数据时，master要异步的将数据同步给slave，而同步之前万一master宕机，就会出现死锁。

为了解决这些问题，可以使用Redission框架

Redission：分布式对象存储和服务的框架，基于Redis实现。

Redission提供了多种分布式锁的实现方式

基于Redis的分布式锁
基于RedLock算法的分布式锁

4.2.1. 基于Redis的分布式锁

前置配置

导入Redission相关依赖
配置Redis地址和端口

创建Redis分布式锁

创建RedissionClient对象，连接到redis节点（ip）；
使用getLock方法获取锁对象（这里用的对象名叫"myLock"）；
try-catch-finally中，使用tryLock方法获取锁，如果成功则执行业务；
执行完业务，通过unlock方法释放锁，并关闭redission。

import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;

public class RedissonLockExample {
    public static void main(String[] args) {
        // 创建Redisson配置对象
        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");

        // 创建Redisson客户端
        RedissonClient redisson = Redisson.create(config);

        // 获取锁对象
        RLock lock = redisson.getLock("myLock");

        try {
            // 尝试获取锁，并设置锁的超时时间为10秒
            boolean locked = lock.tryLock(10, TimeUnit.SECONDS);
            if (locked) {
                // 成功获取到锁，执行业务逻辑
                System.out.println("获取到锁，开始执行业务逻辑");
                Thread.sleep(5000); // 模拟业务逻辑处理时间
            } else {
                // 获取锁失败，执行相应的处理逻辑
                System.out.println("获取锁失败，执行相应的处理逻辑");
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            // 释放锁
            lock.unlock();
            System.out.println("释放锁");
        }

        // 关闭Redisson客户端
        redisson.shutdown();
    }
}

4.2.2. 基于RedLock算法的分布式锁

创建RedLock分布式锁

创建多个Redission对象，分别连接redis节点；
使用getLock方法获取多个不同锁对象；
在try-catch-finally中，调用RedissionRedLock.tryLock方法获取锁，如果成功，则执行业务；
业务执行完后，通过RedissionRedLock.unlock方法释放锁。

import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;

import java.util.concurrent.TimeUnit;

public class RedissonLockExample {
    public static void main(String[] args) {
        // 创建Redisson配置对象
        Config config1 = new Config();
        config1.useSingleServer().setAddress("redis://127.0.0.1:6379");

        Config config2 = new Config();
        config2.useSingleServer().setAddress("redis://127.0.0.1:6380");

        Config config3 = new Config();
        config3.useSingleServer().setAddress("redis://127.0.0.1:6381");

        // 创建Redisson客户端
        RedissonClient redisson1 = Redisson.create(config1);
        RedissonClient redisson2 = Redisson.create(config2);
        RedissonClient redisson3 = Redisson.create(config3);

        // 获取锁对象
        RLock lock1 = redisson1.getLock("myLock");
        RLock lock2 = redisson2.getLock("myLock");
        RLock lock3 = redisson3.getLock("myLock");

        // 尝试获取锁
        try {
            boolean locked = RedissonRedLock.tryLock(lock1, lock2, lock3, 10, TimeUnit.SECONDS);
            if (locked) {
                // 成功获取到锁，执行业务逻辑
                System.out.println("获取到锁，开始执行业务逻辑");
                Thread.sleep(5000); // 模拟业务逻辑处理时间
            } else {
                // 获取锁失败，执行相应的处理逻辑
                System.out.println("获取锁失败，执行相应的处理逻辑");
            }
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            // 释放锁
            RedissonRedLock.unlock(lock1, lock2, lock3);
            System.out.println("释放锁");
        }

        // 关闭Redisson客户端
        redisson1.shutdown();
        redisson2.shutdown();
        redisson3.shutdown();
    }
}

4.3. Watchdog机制

Watchdog（看门狗）：Redis分布式锁中的一种机制机制，用于在分布式环境下对锁自动续期，以防止锁过期而被自动释放。

每个redis锁都有一个有效期，在锁的有效期内，有的线程会因为执行时间较长或遇到阻塞问题，可能会导致锁的持有时间超过了预期，从而造成其他线程在有效期内无法获取到锁，所以Redission优化了这一点，推出看门狗机制，定期延续锁期限，确保锁的延续。

机制

Redission的看门狗使用了Redis的PTTL命令来获取锁的剩余有效期，并在适当的时候发送PEXPIRE命令进行续期，默认续期时间是锁有效期的2/3，且续期操作在每次续期间隔的一半时间内执行，以此确保连续续期。

适用场景

分布式调度：通过watchdog延续锁，确保任务调度中，同一时刻只有一个节点执行任务，保持锁的有效性，防止任务执行时间过长导致锁被自动释放。
缓存预热：通过watchdog延续锁，确保在缓存预热过程中，锁的有效性，实现只有一个节点进行缓存数据的加载和初始化。
分布式限流：通过watchdog延续锁，确保在控制某个资源或服务并发访问量的时候，锁的有效性，防止因锁过期而导致并发访问超出限制。
分布式事务管理：通过watchdog延续锁，确保多个事务完成前多把锁保持有效，防止锁过期导致数据不一致。

五、Redis策略

Redis常用策略：

数据持久化策略：RDB（全量型）快照形式，定期机制；AOF（增量型）日志形式，追加机制。
复制策略：主从复制，将master数据以RDB方式复制到slave。
分片策略：分片集群，海量数据分散到各个集群。
数据过期策略：定期处理过期数据，释放缓存。
数据淘汰策略：

5.1. 数据过期策略（Key过期）

在使用redis的时候，通常会设置数据的过期时间，过了有效期，依旧留在redis内部，这样不断地累积，redis缓存过多，会导致性能降低，为了避免这种现象发生，redis提供了清除过期数据的策略。

redis的数据过期策略：

定时删除（Expired by Time）：设置键的过期时间，到达指定时间后自动删除该键，是redis最常用的过期策略。
惰性删除（Expired by Access）：
定期删除（Expired by Sampling）：定期对Key检查，删除里面过期的Key（从一定量的数据库中取一部分随机数据进行检查，删除其中的过期键）。

5.1.1. 定时删除策略

定时删除策略
通过设置键过期时间来控制数据生命周期，当键的过期时间到达，redis自动删除该键。

以Lettuce客户端为例

实例化RedisClient对象，使用connect方法连接redis；
获取同步执行的RedisCommands对象，使用expire命令（方法）设置键的过期时间；
通过shutdown关闭RedisClient连接。

import io.lettuce.core.RedisClient;
import io.lettuce.core.api.StatefulRedisConnection;
import io.lettuce.core.api.sync.RedisCommands;

public class RedisExample {
    public static void main(String[] args) {
        // 创建RedisClient实例
        RedisClient client = RedisClient.create("redis://localhost:6379");

        // 创建Redis连接
        try (StatefulRedisConnection<String, String> connection = client.connect()) {
            // 获取同步的RedisCommands对象
            RedisCommands<String, String> commands = connection.sync();

            // 设置键的过期时间（以秒为单位）
            String key = "myKey";
            int seconds = 60; // 设置为60秒后过期
            commands.expire(key, seconds);
        } finally {
            // 关闭RedisClient连接
            client.shutdown();
        }
    }
}

5.1.2. 惰性刪除策略

惰性刪除策略
在访问键的时候检查其过期时间，并在需要时进行删除的策略。

以Lettuce客户端为例

创建Redisclient实例，通过connect方法建立redis连接
获取响应式RedisReactiveCommands对象
使用惰性删除策略时，先使用set命令设置键的值，后使用expire命令设置键的过期时间（这里使用了Mono.when和block方法来合并和等待执行结果）。
执行其他业务时，使用ttl命令来获取键的剩余过期时间，通过map操作将过期时间小于0的结果映射为true，默认值设为true，并返回Mono<Boolean>类型，然后通过订阅该Mono对象，在延迟一段时间后输出过期状态。
最后使用del命令删除键，并通过Mono.when和block方法合并和等待删除命令的执行结果。

import io.lettuce.core.RedisClient;
import io.lettuce.core.api.StatefulRedisConnection;
import io.lettuce.core.api.reactive.RedisReactiveCommands;
import reactor.core.publisher.Mono;

import java.time.Duration;
import java.util.concurrent.TimeUnit;

public class RedisExample {
    public static void main(String[] args) throws InterruptedException {
        // 创建RedisClient实例
        RedisClient client = RedisClient.create("redis://localhost:6379");

        // 创建Redis连接
        try (StatefulRedisConnection<String, String> connection = client.connect()) {
            // 获取响应式RedisReactiveCommands对象
            RedisReactiveCommands<String, String> reactiveCommands = connection.reactive();

            // 定义键和过期时间
            String key = "myKey";
            int expirationSeconds = 60; // 过期时间60秒

            // 设置键
            Mono<String> setCommand = reactiveCommands.set(key, "myValue");

            // 设置过期时间并订阅结果
            Mono<String> expireCommand = reactiveCommands.expire(key, expirationSeconds);

            // 合并执行结果
            Mono.when(setCommand, expireCommand).block();

            // ... 执行其他操作 ...

            // 检查键是否过期
            Mono<Boolean> isExpired = reactiveCommands.ttl(key)
                    .map(expiration -> expiration < 0)
                    .defaultIfEmpty(true);

            // 延迟一段时间后输出过期状态
            Thread.sleep(Duration.ofSeconds(5).toMillis());
            isExpired.subscribe(expired -> {
                if (expired) {
                    System.out.println("Key has expired.");
                } else {
                    System.out.println("Key has not expired yet.");
                }
            });

            // 删除键
            Mono<Long> delCommand = reactiveCommands.del(key);

            // 合并执行结果
            Mono.when(delCommand).block();
        } finally {
            // 关闭RedisClient连接
            client.shutdown();
        }
    }
}

5.1.3. 定期删除策略

定期删除策略
每隔一段时间，随机检查一批Key是否过期，如果Key已过期，则redis会删除该键，保证过期键在读取时被删除，不会对未访问的键进行删除。

以Lettuce客户端为例

实例化RedisClient对象，使用connect方法连接redis；
获取异步执行的RedisAsyncCommands对象；
使用ScanIterator循环遍历所有匹配的键，循环中，使用sync方法获取同步命令对象，方便检查键的剩余过期时间，如果键已过期，则使用异步命令对象删除键；
使用shutdown关闭redisclient连接。

注意！
在使用Lettuce库中，异步操作通常会立即返回，需要通过await()方法来等待异步操作完成，或使用响应式编程模型来处理异步结果。在示例中，通过flushCommands().await(Duration.ofSeconds(1))来等待异步删除操作完成。

import io.lettuce.core.RedisClient;
import io.lettuce.core.api.StatefulRedisConnection;
import io.lettuce.core.api.async.RedisAsyncCommands;
import io.lettuce.core.api.reactive.RedisReactiveCommands;
import io.lettuce.core.api.sync.RedisCommands;
import io.lettuce.core.scan.ScanCursor;
import io.lettuce.core.scan.ScanIterator;

import java.time.Duration;

public class RedisExample {
    public static void main(String[] args) {
        // 创建RedisClient实例
        RedisClient client = RedisClient.create("redis://localhost:6379");

        // 创建连接
        try (StatefulRedisConnection<String, String> connection = client.connect()) {
            // 使用异步命令处理
            RedisAsyncCommands<String, String> asyncCommands = connection.async();

            // 定期删除过期键
            ScanCursor scanCursor = ScanCursor.INITIAL;
            ScanIterator<String> scanIterator = ScanIterator
                    .scan(asyncCommands, ScanArgs.Builder.matches("*").count(100).build());

            while (scanIterator.hasNext()) {
                scanCursor = scanIterator.next();
                for (String key : scanIterator.getKeys()) {
                    // 检查是否过期
                    RedisCommands<String, String> syncCommands = connection.sync();
                    if (syncCommands.ttl(key) < 0) {
                        // 删除过期键
                        asyncCommands.del(key);
                    }
                }
            }

            // 同步删除操作
            asyncCommands.flushCommands().await(Duration.ofSeconds(1));
        } finally {
            // 关闭连接
            client.shutdown();
        }
    }
}

5.1.4. 延迟过期策略

延迟过期策略
当一个键到达有效期时，redis不会立即执行删除，而是将其标记为"待删除"，等后台的异步任务定期清理这些待删除键。

在Redis中，没有内置的延迟过期策略，通过Scored Sorted Set（有序集合）来实现一种类似的延迟过期策略

以Lettuce客户端为例

使用一个有序集合delayedKeys来存储需要延迟过期的键。调用zadd方法将键添加到有序集合中，设置相关的过期时间。通过zadd命令，键的过期时间存储为成员的分数，使用当前时间戳加上延迟秒数计算得到，以毫秒为单位。

在执行其他操作时，可以使用zrank方法来检查键是否过期。如果返回值不等于-1，则表示键还未过期。如果返回值等于-1，则表示键已过期。

最后，在适当的时候可以使用del命令从Redis中删除键，并调用zrem命令从有序集合中移除该键。

import io.lettuce.core.RedisClient;
import io.lettuce.core.api.StatefulRedisConnection;
import io.lettuce.core.api.sync.RedisCommands;

import java.time.Duration;

public class RedisExample {
    public static void main(String[] args) {
        // 创建RedisClient实例
        RedisClient client = RedisClient.create("redis://localhost:6379");

        // 创建Redis连接
        try (StatefulRedisConnection<String, String> connection = client.connect()) {
            // 获取同步的RedisCommands对象
            RedisCommands<String, String> commands = connection.sync();

            // 定义键和过期时间
            String key = "myKey";
            int delayInSeconds = 60; // 延迟60秒过期

            // 设置键并延迟过期
            commands.zadd("delayedKeys", System.currentTimeMillis() + (delayInSeconds * 1000), key);

            // ... 执行其他操作 ...

            // 检查键是否过期
            if (!commands.zrank("delayedKeys", key).equals(-1L)) {
                // 键还未过期，执行相应操作
                System.out.println("Key has not expired yet.");
            } else {
                // 键已过期，执行相应操作
                System.out.println("Key has expired.");
            }

            // 删除过期键
            commands.del(key);
            // 在有序集合中移除该键
            commands.zrem("delayedKeys", key);
        } finally {
            // 关闭RedisClient连接
            client.shutdown();
        }
    }
}

5.2. 数据淘汰策略（内存不足）

当Redis的内存空间不足时，向Redis中添加新的Key，那么Redis就会按照某种规则将内存中的数据删除，以便新的数据存入进来，这种数据的删除规则就称为内存的淘汰策略。

常见的数据淘汰策略

淘汰具有过期时间的数据

volatile-lru（least recently used）：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。
volatile-lfu（least frequently used）：从已设置过期时间的数据集中挑选最不经常使用的数据淘汰。
volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰。
volatile-random：从已设置过期时间的数据集中任意选择数据淘汰。

淘汰全库数据

allkeys-lru：当内存不足以容纳新写入内存时，在键空间中，移除最近最少使用的key（最常用）
allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key。
allkeys-random：从数据集中任意选择数据淘汰。

不淘汰

no-eviction：禁止驱逐数据，当内存不足以容纳新写入数据时，写入操作会报错（没见人用过）。

LUR：最少最近使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
LFU：最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。
volatile：设置了带过期时间的key。
allkeys：表示所有的key。

常见配置

maxmemory-policy noeviction		# 配置淘汰策略
maxmemory ?mb					# 最大可使用内存,即占用物理内存的比例,默认为0,表示不限制。生产环境通常设置在50%以上。
maxmemory-samples count 		# 设置redis需要检查key的个数

六、Redis缓存问题

6.1. 缓存穿透

缓存穿透：指客户端请求的数据在缓存中和数据库中都不存在，请求穿过缓存，冲击数据库。

当客户端访问数据时，先请求redis，但redis此时并没有数据，那么请求就会继续访问到数据库，但此时数据库中也没有该数据，这个数据就穿透了缓存，直接访问数据库，而数据库承载的并发又远不如redis高，如果大量的请求同时访问这种不存在的数据，那么数据库受到的压力会非常大。
在这里插入图片描述

缓存穿透解决方案

解决方案	优点	缺点
缓存空对象	实现简单，维护方便	额外的内存消耗，可能造成短期的不一致
布隆过滤器	内存占用较少，没有多余的key	实现复杂，存在误判可能