Redis缓存学习笔记

一、Redis的常用数据结构

1.1 String

String 是 Redis 中最简单同时也是最常用的一个数据结构。

String 是一种二进制安全的数据结构，可以用来存储任何类型的数据比如字符串、整数、浮点数、图片（图片的 base64 编码或者解码或者图片的路径）、序列化后的对象。

应用场景：存储常规数据。举例：缓存 session、token、图片地址、分布式锁

1.2 List

Redis 中的 List 其实就是链表数据结构的实现。

许多高级编程语言都内置了链表的实现比如 Java 中的 LinkedList，但是 C 语言并没有实现链表，所以 Redis 实现了自己的链表数据结构。Redis 的 List 的实现为一个 双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。

应用场景：

• 信息展示：最新文章、最新动态
• 信息队列（不建议使用）

1.3 Hash

Redis 中的 Hash 是一个 String 类型的 field-value（键值对） 的映射表，特别适合用于存储对象，后续操作的时候，你可以直接修改这个对象中的某些字段的值。

Hash 类似于 JDK1.8 前的 HashMap，内部实现也差不多(数组 + 链表)。不过，Redis 的 Hash 做了更多优化。

应用场景：

• 对象存储：用户信息、商品信息、文章信息、购物车信息等。

1.4 Set

Redis 中的 Set 类型是一种无序集合，集合中的元素没有先后顺序但都唯一，有点类似于 Java 中的 HashSet 。当你需要存储一个列表数据，又不希望出现重复数据时，Set 是一个很好的选择，并且 Set 提供了判断某个元素是否在一个 Set 集合内的重要接口，这个也是 List 所不能提供的。

你可以基于 Set 轻易实现交集、并集、差集的操作，比如你可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。这样的话，Set 可以非常方便的实现如共同关注、共同粉丝、共同喜好等功能。这个过程也就是求交集的过程。

应用场景：

• 共同好友(交集)、共同粉丝(交集)、共同关注(交集)、好友推荐（差集）、音乐推荐（差集）、订阅号推荐（差集+交集） 等场景。
• 抽奖系统、随机点名等场景。相关命令：SPOP（随机获取集合中的元素并移除，适合不允许重复中奖的场景）、SRANDMEMBER（随机获取集合中的元素，适合允许重复中奖的场景）。

1.5 Zset 

有序集合类型相比于集合类型多了  排序属性 score（分值），每个存储元素有两个值组成，一个是元素值，一个是排序值。有序集合的元素值也是不能重复，但分值可以重复。

应用场景：排序场景。

二、Redis持久化机制

使用缓存的时候，我们经常需要对内存中的数据进行持久化也就是将内存中的数据写入到硬盘中。大部分原因是为了之后重用数据（比如重启机器、机器故障之后恢复数据），或者是为了做数据同步（比如 Redis 集群的主从节点通过 RDB 文件同步数据）。

Redis 不同于 Memcached 的很重要一点就是，Redis 支持持久化，而且支持 3 种持久化方式:

• 快照（snapshotting，RDB）
• 只追加文件（append-only file, AOF）
• RDB 和 AOF 的混合持久化(Redis 4.0 新增)

RDB持久化

Redis 可以通过创建快照来获得存储在内存里面的数据在 某个时间点 上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用。

快照持久化是 Redis 默认采用的持久化方式，在 redis.conf 配置文件中默认有此下配置：

save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发bgsave命令创建快照。

save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发bgsave命令创建快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发bgsave命令创建快照。

AOF持久化

与快照持久化相比，AOF 持久化的实时性更好。默认情况下 Redis 没有开启 AOF（append only file）方式的持久化（Redis 6.0 之后已经默认是开启了），可以通过 appendonly 参数开启：

appendonly yes

开启 AOF 持久化后每执行一条会更改 Redis 中的数据的命令，Redis 就会将该命令写入到 AOF 缓冲区 server.aof_buf 中，然后再写入到 AOF 文件中（此时还在系统内核缓存区未同步到磁盘），最后再根据持久化方式（ fsync策略）的配置来决定何时将系统内核缓存区的数据同步到硬盘中的。

只有同步到磁盘中才算持久化保存了，否则依然存在数据丢失的风险，比如说：系统内核缓存区的数据还未同步，磁盘机器就宕机了，那这部分数据就算丢失了。

在 Redis 的配置文件中存在三种不同的 AOF 持久化方式（ fsync策略），它们分别是：

1. appendfsync always：主线程调用 write 执行写操作后，后台线程（ aof_fsync 线程）立即会调用 fsync 函数同步 AOF 文件（刷盘），fsync 完成后线程返回，这样会严重降低 Redis 的性能（write + fsync）。
2. appendfsync everysec：主线程调用 write 执行写操作后立即返回，由后台线程（ aof_fsync 线程）每秒钟调用 fsync 函数（系统调用）同步一次 AOF 文件（write+fsync，fsync间隔为 1 秒）
3. appendfsync no：主线程调用 write 执行写操作后立即返回，让操作系统决定何时进行同步，Linux 下一般为 30 秒一次（write但不fsync，fsync 的时机由操作系统决定）。

综上，如何选择RDB与AOF：

• Redis 保存的数据丢失一些也没什么影响的话，可以选择使用 RDB。
• 不建议单独使用 AOF，因为时不时地创建一个 RDB 快照可以进行数据库备份、更快的重启以及解决 AOF 引擎错误。
• 如果保存的数据要求安全性比较高的话，建议同时开启 RDB 和 AOF 持久化或者开启 RDB 和 AOF 混合持久化。

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

3.1 缓存穿透

缓存穿透是指查询一个缓存中和数据库中都不存在的数据，导致每次查询这条数据都会透过缓存，直接查库，最后返回空。当用户使用这条不存在的数据疯狂发起查询请求的时候，对数据库造成的压力就非常大，甚至可能直接挂掉。

解决缓存穿透的方法一般有两种，第一种是缓存空对象，第二种是使用布隆过滤器。

第一种方法比较好理解，就是当数据库中查不到数据的时候，我缓存一个空对象，然后给这个空对象的缓存设置一个过期时间，这样下次再查询该数据的时候，就可以直接从缓存中拿到，从而达到了减小数据库压力的目的。但这种解决方式有两个缺点：（1）需要缓存层提供更多的内存空间来缓存这些空对象，当这种空对象很多的时候，就会浪费更多的内存；（2）会导致缓存层和存储层的数据不一致，即使在缓存空对象时给它设置了一个很短的过期时间，那也会导致这一段时间内的数据不一致问题。

第二种方案是使用布隆过滤器，这是比较推荐的方法。所谓布隆过滤器，就是一种数据结构，它是由一个长度为m bit的位数组与n个hash函数组成的数据结构，位数组中每个元素的初始值都是0。在初始化布隆过滤器时，会先将所有key进行n次hash运算，这样就可以得到n个位置，然后将这n个位置上的元素改为1。这样，就相当于把所有的key保存到了布隆过滤器中了。

3.2 缓存击穿

缓存击穿是指当缓存中某个热点数据过期了，在该热点数据重新载入缓存之前，有大量的查询请求穿过缓存，直接查询数据库。这种情况会导致数据库压力瞬间骤增，造成大量请求阻塞，甚至直接挂掉。

解决缓存击穿的方法也有两种，第一种是设置key永不过期；第二种是使用分布式锁，保证同一时刻只能有一个查询请求重新加载热点数据到缓存中，这样，其他的线程只需等待该线程运行完毕，即可重新从Redis中获取数据。

第一种方式比较简单，在设置热点key的时候，不给key设置过期时间即可。不过还有另外一种方式也可以达到key不过期的目的，就是正常给key设置过期时间，不过在后台同时启一个定时任务去定时地更新这个缓存。

第二种方式使用了加锁的方式，锁的对象就是key，这样，当大量查询同一个key的请求并发进来时，只能有一个请求获取到锁，然后获取到锁的线程查询数据库，然后将结果放入到缓存中，然后释放锁，此时，其他处于锁等待的请求即可继续执行，由于此时缓存中已经有了数据，所以直接从缓存中获取到数据返回，并不会查询数据库。

3.3 缓存雪崩

缓存雪崩是指当缓存中有大量的key在同一时刻过期，或者Redis直接宕机了，导致大量的查询请求全部到达数据库，造成数据库查询压力骤增，甚至直接挂掉。

针对第一种大量key同时过期的情况，解决起来比较简单，只需要将每个key的过期时间打散即可，使它们的失效点尽可能均匀分布。

针对第二种redis发生故障的情况，部署redis时可以使用redis的几种高可用方案部署。

除了上面两种解决方式，还可以使用其他策略，比如设置key永不过期、加分布式锁等。

四、布隆过滤器

布隆过滤器（Bloom Filter）是 1970 年由布隆提出的，是一种非常节省空间的概率数据结构，运行速度快，占用内存小，但是有一定的误判率且无法删除元素。它实际上是一个很长的二进制向量和一系列随机映射函数组成，主要用于判断一个元素是否在一个集合中。

通常我们都会遇到判断一个元素是否在某个集合中的业务场景，这个时候我们可能都是采用 HashMap的Put方法或者其他集合将数据保存起来，然后进行比较确定，但是如果元素很多的情况下，采用这种方式就会非常浪费空间，最终达到瓶颈，检索速度也会越来越慢，这时布隆过滤器（Bloom Filter）就应运而生了。

布隆过滤器原理介绍

当一个元素加入布隆过滤器中的时候，会进行如下操作：

1. 使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。
2. 根据得到的哈希值，在位数组中把对应下标的值置为 1。

当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行如下操作：

1. 对给定元素再次进行相同的哈希计算；
2. 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。

布隆过滤器使用场景

1. 判断给定数据是否存在：比如判断一个数字是否存在于包含大量数字的数字集中（数字集很大，上亿）、 防止缓存穿透（判断请求的数据是否有效避免直接绕过缓存请求数据库）等等、邮箱的垃圾邮件过滤（判断一个邮件地址是否在垃圾邮件列表中）、黑名单功能（判断一个IP地址或手机号码是否在黑名单中）等等。
2. 去重：比如爬给定网址的时候对已经爬取过的 URL 去重、对巨量的 QQ号/订单号去重。

去重场景也需要用到判断给定数据是否存在，因此布隆过滤器主要是为了解决海量数据的存在性问题。

使用 Google 开源的 Guava 中自带的布隆过滤器

首先我们需要在项目中引入 Guava 的依赖：

    com.google.guava
    guava
    31.0.1-jre

实际使用如下：创建一个最多存放 最多 1500 个整数的布隆过滤器，并且可以容忍误判的概率为百分之0.01。

// 创建布隆过滤器对象
BloomFilter filter = BloomFilter.create(
    Funnels.integerFunnel(),
    1500,
    0.01);
// 判断指定元素是否存在
System.out.println(filter.mightContain(1));
System.out.println(filter.mightContain(2));
// 将元素添加进布隆过滤器
filter.put(1);
filter.put(2);
System.out.println(filter.mightContain(1));
System.out.println(filter.mightContain(2));

当 mightContain() 方法返回 true 时，我们可以 99％确定该元素在过滤器中，当过滤器返回 false 时，我们可以 100％确定该元素不存在于过滤器中。执行结果为：

Java集成Redis使用布隆过滤器

首先引入依赖：

   org.redisson
   redisson-spring-boot-starter
   3.13.1

 编写代码测试：

	public void patchingConsum(ConsumPatchingVO vo) throws ParseException {
		Config config = new Config();
		SingleServerConfig singleServerConfig = config.useSingleServer();
		singleServerConfig.setAddress("redis://127.0.0.1:6379");
		//singleServerConfig.setPassword("123456");
		RedissonClient redissonClient = Redisson.create(config);
		RBloomFilter bloom = redissonClient.getBloomFilter("name");
		// 初始化布隆过滤器；  大小:100000，误判率:0.01
		bloom.tryInit(100000L, 0.01);
		// 新增10万条数据
		for(int i=0;i<100000;i++) {
			bloom.add("name" + i);
		}
		// 判断不存在于布隆过滤器中的元素
		List notExistList = new ArrayList<>();
		for(int i=0;i<100000;i++) {
			String str = "name" + i;
			boolean notExist = bloom.contains(str);
			if (notExist) {
				notExistList.add(str);
			}
		}
		if ($.isNotEmpty(notExistList) && notExistList.size() > 0 ) {
			System.out.println("误判次数:"+notExistList.size());
		}

	}

五、如何保证数据一致性

我们使用Redis来作为缓存时，让请求先访问到Redis，而不是直接访问数据库。而在这种业务场景下，可能会出现缓存和数据库数据不一致性的问题。数据一致性问题有以下四种：

先更新缓存，再更新数据库

如果我成功更新了缓存，但是在执行更新数据库的那一步，服务器突然宕机了，那么此时，我的缓存中是最新的数据，而数据库中是旧的数据。

脏数据就因此诞生了，并且如果我缓存的信息（是单独某张表的），而且这张表也在其他表的关联查询中，那么其他表关联查询出来的数据也是脏数据，结果就是直接会产生一系列的问题。

先更新数据库，在更新缓存

只有等到缓存过期之后，才能访问到正确的信息。那么在缓存没过期的时间段内，所看到的都是脏数据。

先删除缓存，在更新数据库

这种方式在没有高并发的情况下，是可能保持数据一致性的。

如果只有第一步执行成功，而第二步失败，那么只有缓存中的数据被删除了，但是数据库没有更新，那么在下一次进行查询的时候，查不到缓存，只能重新查询数据库，构建缓存，这样其实也是相对做到了数据一致性。

先更新数据库，在删除缓存

如果更新数据库成功了，而删除缓存失败了，那么数据库中就会是新数据，而缓存中是旧数据，数据就出现了不一致情况。

以上四种方式无论选择那种方式，如果实在多服务或时并发的情况下，其实都是有可能产生数据不一致性的。为了解决这个存在的问题有以下方式：

延迟双删

先进行缓存清除，再执行update，最后（延迟N秒）再执行缓存清除。进行两次删除，且中间需要延迟一段时间，延迟删除的时间需要大于 业务执行流程的总时间。

六、Redis实现分布式锁

在多线程环境中，如果多个线程同时访问共享资源（例如商品库存、外卖订单），会发生数据竞争，可能会导致出现脏数据或者系统问题，威胁到程序的正常运行。为了保证共享资源被安全地访问，我们需要使用互斥操作对共享资源进行保护，即同一时刻只允许一个线程访问共享资源，其他线程需要等待当前线程释放后才能访问。这样可以避免数据竞争和脏数据问题，保证程序的正确性和稳定性。

对于单机多线程来说，在 Java 中，我们通常使用 ReetrantLock 类、synchronized 关键字这类 JDK 自带的 本地锁 来控制一个 JVM 进程内的多个线程对本地共享资源的访问。

分布式系统下，不同的服务/客户端通常运行在独立的 JVM 进程上。如果多个 JVM 进程共享同一份资源的话，使用本地锁就没办法实现资源的互斥访问了。于是，分布式锁 就诞生了。

分布式锁实现方案

分布式锁都是通过第三方组件来实现的，目前比较流行的分布式锁的解决方案有：

1、数据库，通过数据库可以实现分布式锁，但是在高并发的情况下对数据库压力较大，所以很少使用。
2、Redis，借助Redis也可以实现分布式锁，而且Redis的Java客户端种类很多，使用的方法也不尽相同。
3、Zookeeper，Zookeeper也可以实现分布式锁，同样Zookeeper也存在多个Java客户端，使用方法也不相同

利用Redis实现分布式锁

基本方案：在 Redis 中， SETNX 命令是可以帮助我们实现互斥。SETNX 即 SET if Not eXists (对应 Java 中的 setIfAbsent 方法)，如果 key 不存在的话，才会设置 key 的值。如果 key 已经存在， SETNX 啥也不做。完成之后将锁删除，完成一个简单的分布式锁方案。

@PutMapping("/deduct_stock1")
    public String deductStock1(){
        redisTemplate.opsForValue().setIfAbsent("goods:001","1");
        int total=Integer.parseInt((String) redisTemplate.opsForValue().get("goods:001"));
        if(total>0){
            int realTotal=total-1;
            redisTemplate.opsForValue().set("goods:001",String.valueOf(realTotal));
            System.out.println("购买商品成功，库存还剩:"+realTotal+"件");
            redisTemplate.delete("goods:001");
            return "购买商品成功，库存还剩:"+realTotal+"件";
        }else {
            return "购买商品失败，库存已无商品";
        }
    }

为了防止误删到其他的锁，这里我们建议使用 Lua 脚本通过 key 对应的 value（唯一值）来判断。

选用 Lua 脚本是为了保证解锁操作的原子性。因为 Redis 在执行 Lua 脚本时，可以以原子性的方式执行，从而保证了锁释放操作的原子性。

// 释放锁时，先比较锁对应的 value 值是否相等，避免锁的误释放
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

 如果执行过程中出现异常，程序就直接抛出异常退出，导致锁没有释放造成最终死锁的问题。（即使将锁放在finally中释放，但是假如是执行到中途系统宕机，锁还是没有被成功的释放掉，依然会出现死锁现象）

方案改进：可以给锁设置一个超时时间，到时自动释放锁（锁的过期时间大于业务执行时间）

redisTemplate.opsForValue().setIfAbsent(REDIS_LOCK,value,1,TimeUnit.MINUTES);

 对于Java开发者来说，已经有了成熟的解决方案来解决分布式锁的问题：Redisson。

Redisson 中的分布式锁自带自动续期机制，使用起来非常简单，原理也比较简单，其提供了一个专门用来监控和续期锁的 Watch Dog（ 看门狗），如果操作共享资源的线程还未执行完成的话，Watch Dog 会不断地延长锁的过期时间，进而保证锁不会因为超时而被释放。

@PutMapping("/deduct_stock3")
    public String deductStock5(){
        String REDIS_LOCK="good_lock";
        String value= "100";
        RLock redissionLock=redisson.getLock(REDIS_LOCK);
        redissionLock.lock();
        if(null==redissionLock){
            return "抢锁失败";
        }
        System.out.println(value+"抢锁成功");

        int total=Integer.parseInt((String) redisTemplate.opsForValue().get(REDIS_LOCK));
        if(total>0){
            int realTotal=total-1;
            System.out.println("购买商品成功，库存还剩:"+realTotal+"件");
            return "购买商品成功，库存还剩:"+realTotal+"件";
        }else {
            System.out.println("购买商品失败，库存已无商品");
        }
        redissionLock.unlock();
        return "购买商品失败，库存已无商品";
    }

Redission执行流程如下：（只要线程一加锁成功，就会启动一个watch dog看门狗，它是一个后台线程，会每隔10秒检查一下（锁续命周期就是设置的超时时间的三分之一），如果线程还持有锁，就会不断的延长锁key的生存时间。因此，Redis就是使用Redisson解决了锁过期释放，业务没执行完问题。当业务执行完，释放锁后，再关闭守护线程，

七、Redis实现幂等性校验

在实际的开发项目中,一个对外暴露的接口往往会面临很多次请求，幂等的概念：任意多次执行所产生的影响均与一次执行的影响相同。按照这个含义，最终的含义就是 对数据库的影响只能是一次性的，不能重复处理。

如何保证其幂等性，通常有以下手段：

1. 数据库建立唯一性索引，可以保证最终插入数据库的只有一条数据

2. token机制，每次接口请求前先获取一个token，然后再下次请求的时候在请求的header体中加上这个token，后台进行验证，如果验证通过删除token，下次请求再次判断token

3. 悲观锁或者乐观锁，悲观锁可以保证每次for update的时候其他sql无法update数据(在数据库引擎是innodb的时候,select的条件必须是唯一索引,防止锁全表)

4. 先查询后判断，首先通过查询数据库是否存在数据，如果存在证明已经请求过了，直接拒绝该请求，如果没有存在，就证明是第一次进来，直接放行。

接下来我们使用Redis实现Token来解决接口幂等性问题：

token的创建与校验

public interface TokenService {

    /**
     * 创建token
     * @return
     */
    String createToken();

    /**
     * 检验token
     * @param request
     * @return
     */
    boolean checkToken(HttpServletRequest request) throws Exception;

}

@Service
public class TokenServiceImpl implements TokenService {

    public static final String TOKEN_NAME = "token";
    public static final String  TOKEN_PREFIX="token-xxx";
    public static final String  ResponseCode_ILLEGAL_ARGUMENT="100";
    public static final String  ResponseCode_REPETITIVE_OPERATION="200";

    @Autowired
    private RedisService redisService;

    /**
     * 创建token
     *
     * @return
     */
    @Override
    public String createToken() {
        String str = UUID.randomUUID().toString();
        //StrBuilder token = new StrBuilder();
        StringBuilder token=new StringBuilder();
        try {
            token.append(TOKEN_PREFIX).append(str);
            redisService.setEx(token.toString(), token.toString(),10000L);
            boolean notEmpty = StringUtils.isNotBlank(token.toString());
            if (notEmpty) {
                return token.toString();
            }
        }catch (Exception ex){
            ex.printStackTrace();
        }
        return null;
    }


    /**
     * 检验token
     *
     * @param request
     * @return
     */
    @Override
    public boolean checkToken(HttpServletRequest request) throws Exception {

        String token = request.getHeader(TOKEN_NAME);
        if (StringUtils.isBlank(token)) {// header中不存在token
            token = request.getParameter(TOKEN_NAME);
            if (StringUtils.isBlank(token)) {// parameter中也不存在token
                //throw new ServiceException(ResponseCode_ILLEGAL_ARGUMENT, 100);
                System.out.println("ResponseCode_ILLEGAL_ARGUMENT:100");
                throw new RuntimeException("tokenservice:校验失败111");
            }
        }

        if (!redisService.exists(token)) {
            //throw new ServiceException(ResponseCode_REPETITIVE_OPERATION, 200);
            System.out.println("ResponseCode_REPETITIVE_OPERATION:200");
            throw new RuntimeException("tokenservice:校验失败222");
        }

        boolean remove = redisService.remove(token);
        if (!remove) {
            //throw new ServiceException(ResponseCode_REPETITIVE_OPERATION, 200);
            System.out.println("ResponseCode_REPETITIVE_OPERATION:200");

            throw new RuntimeException("tokenservice:校验失败333");

        }
        return true;
    }

 自定义注解

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface AutoIdempotent {}

自定义一个注解，定义此注解的主要目的是把它添加在需要实现幂等的方法上，凡是某个方法注解了它，都会实现自动幂等。后台利用反射如果扫描到这个注解，就会处理这个方法实现自动幂等，使用元注解ElementType.METHOD表示它只能放在方法上，etentionPolicy.RUNTIME表示它在运行时

拦截器处理

拦截器主要的功能是拦截扫描到AutoIdempotent到注解到方法,然后调用tokenService的checkToken()方法校验token是否正确，如果捕捉到异常就将异常信息渲染成json返回给前端

/**
 * 拦截器
 */
@Component
public class AutoIdempotentInterceptor implements HandlerInterceptor {

    @Autowired
    private TokenService tokenService;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        if (!(handler instanceof HandlerMethod)) {
            return true;
        }
        HandlerMethod handlerMethod = (HandlerMethod) handler;
        Method method = handlerMethod.getMethod();
        //被ApiIdempotment标记的扫描
        AutoIdempotent methodAnnotation = method.getAnnotation(AutoIdempotent.class);
        if (methodAnnotation != null) {
            try {
                return tokenService.checkToken(request);// 幂等性校验, 校验通过则放行, 校验失败则抛出异常, 并通过统一异常处理返回友好提示
            }catch (Exception ex){

                System.out.println("幂等性校验失败");
                throw ex;
            }
        }
        return true;
    }


    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {

    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
    }

    /**
     * 返回的json值
     */
    private void writeReturnJson(HttpServletResponse response, String json) throws Exception{
        PrintWriter writer = null;
        response.setCharacterEncoding("UTF-8");
        response.setContentType("text/html; charset=utf-8");
        try {
            writer = response.getWriter();
            writer.print(json);

        } catch (IOException e) {
        } finally {
            if (writer != null)
                writer.close();
        }
    }

}

代码测试

@RestController
public class BusinessController {

    @Resource
    private TokenService tokenService;

    @Resource
    private StudentService studentService;

    @PostMapping("/get/token")
    public ResultVo getToken(){
        String token = tokenService.createToken();
        if (StringUtils.isNotBlank(token)) {
            ResultVo resultVo = new ResultVo();
            resultVo.setCode("200");
            resultVo.setMessage("success");
            resultVo.setData(token);
            //return JSONUtil.toJsonStr(resultVo);
            return resultVo;
        }
        return null;
    }

    @AutoIdempotent
    @PostMapping("/test/Idempotence")
    public String testIdempotence() {
        Student student=new Student();
        student.setSname("小白");
        student.setSage(20);
        student.setSdept("test");
        student.setSsex("male");
        boolean save = studentService.save(student);
        if (save==true) {
            return "添加成功";
        }
        return "添加失败";
    }
}

首先我们访问获取token接口获取token：

然后将生成的token放入请求头中

发送请求： 

 

 第二次请求，返回到是重复性操作，可见重复性验证通过，再多次请求到时候我们只让其第一次成功，第二次就是失败：

八、缓存淘汰机制

Redis 提供 6 种数据淘汰策略：

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

4.0 版本后增加以下两种：

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