前言

在这里插入图片描述

本文小新为大家带来 Redis缓存 相关知识，具体内容包括Jedis客户端（包括：Jedis简介，创建工程，使用 Jedis 实例，使用 JedisPool，使用 JedisPooled，连接 Sentinel 高可用集群，连接分布式系统，操作事务），高并发问题（包括：缓存穿透，缓存击穿，缓存雪崩，数据库缓存双写不一致）等进行详尽介绍~

不积跬步，无以至千里；不积小流，无以成江海。每天进步一点点，在成为强者的路上，小新与大家共同成长！

📌博主主页：小新要变强的主页
👉Java全栈学习路线可参考：【Java全栈学习路线】最全的Java学习路线及知识清单，Java自学方向指引，内含最全Java全栈学习技术清单~
👉算法刷题路线可参考：算法刷题路线总结与相关资料分享，内含最详尽的算法刷题路线指南及相关资料分享~
👉Java微服务开源项目可参考：企业级Java微服务开源项目（开源框架，用于学习、毕设、公司项目、私活等，减少开发工作，让您只关注业务！）

🚩欢迎关注小新的Git仓库：小新Java成长之路，不定期更新Java学习资料~

↩️本文上接：超详细Redis入门教程——Redis分布式系统

前言
目录
一、Jedis客户端
- 1️⃣Jedis简介
- 2️⃣创建工程
- 3️⃣使用 Jedis 实例
- 4️⃣使用 JedisPool
- 5️⃣使用 JedisPooled
- 6️⃣连接 Sentinel 高可用集群
- 7️⃣连接分布式系统
- 8️⃣操作事务
二、高并发问题
- 1️⃣缓存穿透
- 2️⃣缓存击穿
- 3️⃣缓存雪崩
- 4️⃣数据库缓存双写不一致
后记

在这里插入图片描述

一、Jedis客户端

1️⃣Jedis简介

Jedis 是一个基于 java 的 Redis 客户端连接工具，旨在提升性能与易用性。

其 github 上的官网地址为：https://github.com/redis/jedis。

下面我们创建一个工程，通过具体的实例来对Jedis的使用进行介绍。

2️⃣创建工程

<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
</properties>
<dependencies>
    <!--jedis 依赖-->
    <dependency>
        <groupId>redis.clients</groupId>
        <artifactId>jedis</artifactId>
        <version>4.2.0</version>
    </dependency>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.11</version>
        <scope>test</scope>
    </dependency>
</dependencies>

3️⃣使用 Jedis 实例

Jedis 基本使用十分简单，其提供了非常丰富的操作 Redis 的方法，而这些方法名几乎与Redis 命令相同。在每次使用时直接创建 Jedis 实例即可。在 Jedis 实例创建好之后，Jedis 底层实际会创建一个到指定 Redis 服务器的 Socket 连接。所以，为了节省系统资源与网络带宽，在每次使用完 Jedis 实例之后，需要立即调用 close()方法将连接关闭。

首先，需要在工程的 src/test/java 下创建测试类 JedisTest。

🍀（1）value 为 String 的测试

在这里插入图片描述

🍀（2）value 为 Hash 的测试

在这里插入图片描述

🍀（3）value 为 List 的测试

在这里插入图片描述

🍀（4）value 为 Set 的测试

在这里插入图片描述

🍀（5）value 为 ZSet 的测试

在这里插入图片描述

4️⃣使用 JedisPool

如果应用非常频繁地创建和销毁 Jedis 实例，虽然节省了系统资源与网络带宽，但会大大降低系统性能。因为创建和销毁 Socket 连接是比较耗时的。此时可以使用 Jedis 连接池来解决该问题。

使用 JedisPool 与使用 Jedis 实例的区别是，JedisPool 是全局性的，整个类只需创建一次即可，然后每次需要操作 Redis 时，只需从 JedisPool 中拿出一个 Jedis 实例直接使用即可。

使用完毕后，无需释放 Jedis 实例，只需返回 JedisPool 即可。

在这里插入图片描述

5️⃣使用 JedisPooled

对于每次对 Redis 的操作都需要使用 try-with-resource 块是比较麻烦的，而使用JedisPooled 则无需再使用该结构来自动释放资源了。

在这里插入图片描述

6️⃣连接 Sentinel 高可用集群

对于 Sentinel 高可用集群的连接，直接使用 JedisSentinelPool 即可。在该客户端只需注册所有 Sentinel 节点及其监控的 Master 的名称即可，无需出现 master-slave 的任何地址信息。

其采用的也是 JedisPool，使用完毕的 Jedis 也需要通过 close()方法将其返回给连接池。

在这里插入图片描述

7️⃣连接分布式系统

对于 Redis 的分布式系统的连接，直接使用 JedisCluster 即可。其底层采用的也是 Jedis 连接池技术。每次使用完毕后，无需显式关闭，其会自动关闭。

对于 JedisCluster 常用的构造器有两个。一个是只需一个集群节点的构造器，这个节点可以是集群中的任意节点，只要连接上了该节点，就连接上了整个集群。但该构造器存在一个风险：其指定的这个节点在连接之前恰好宕机，那么该客户端将无法连接上集群。所以，推荐使用第二个构造器，即将集群中所有节点全部罗列出来。这样就会避免这种风险了。

在这里插入图片描述

8️⃣操作事务

对于 Redis 事务的操作，Jedis 提供了 multi()、watch()、unwatch()方法来对应 Redis 中的 multi、watch、unwatch 命令。Jedis 的 multi()方法返回一个 Transaction 对象，其 exec()与 discard() 方法用于执行和取消事务的执行。

🍀（1）抛出 Java 异常

在这里插入图片描述

其输出结果为全部回滚的结果。

在这里插入图片描述

🍀（2）捕获Redis 异常

在这里插入图片描述

其输出结果为修改过的值。说明 Redis 运行时抛出的异常不会被 Java 代码捕获到，其不会影响 Java 代码的执行。

在这里插入图片描述

🍀（3）watch()

在这里插入图片描述

二、高并发问题

Redis 做缓存虽减轻了 DBMS 的压力，减小了 RT，但在高并发情况下也是可能会出现各种问题的。

1️⃣缓存穿透

当用户访问的数据既不在缓存也不在数据库中时，就会导致每个用户查询都会“穿透” 缓存“直抵”数据库。这种情况就称为缓存穿透。当高度发的访问请求到达时，缓存穿透不仅增加了响应时间，而且还会引发对 DBMS 的高并发查询，这种高并发查询很可能会导致DBMS 的崩溃。

缓存穿透产生的主要原因有两个：一是在数据库中没有相应的查询结果，二是查询结果为空时，不对查询结果进行缓存。所以，针对以上两点，解决方案也有两个：

对非法请求进行限制
对结果为空的查询给出默认值

2️⃣缓存击穿

对于某一个缓存，在高并发情况下若其访问量特别巨大，当该缓存的有效时限到达时，可能会出现大量的访问都要重建该缓存，即这些访问请求发现缓存中没有该数据，则立即到 DBMS 中进行查询，那么这就有可能会引发对 DBMS 的高并发查询，从而接导致 DBMS 的崩溃。这种情况称为缓存击穿，而该缓存数据称为热点数据。

对于缓存击穿的解决方案，较典型的是使用“双重检测锁”机制。

3️⃣缓存雪崩

对于缓存中的数据，很多都是有过期时间的。若大量缓存的过期时间在同一很短的时间段内几乎同时到达，那么在高并发访问场景下就可能会引发对 DBMS 的高并发查询，而这将可能直接导致 DBMS 的崩溃。这种情况称为缓存雪崩。

对于缓存雪崩没有很直接的解决方案，最好的解决方案就是预防，即提前规划好缓存的过期时间。要么就是让缓存永久有效，当 DB 中数据发生变化时清除相应的缓存。如果 DBMS 采用的是分布式部署，则将热点数据均匀分布在不同数据库节点中，将可能到来的访问负载均衡开来。

4️⃣数据库缓存双写不一致

以上三种情况都是针对高并发读场景中可能会出现的问题，而数据库缓存双写不一致问题，则是在高并发写场景下可能会出现的问题。

对于数据库缓存双写不一致问题，以下两种场景下均有可能会发生：

🍀（1）“修改 DB 更新缓存”场景

对于具有缓存 warmup 功能的系统，DBMS 中常用数据的变更，都会引发缓存中相关数据的更新。在高并发写请求场景下，若多个请求要对 DBMS 中同一个数据进行修改，修改后还需要更新缓存中相关数据，那么就有可能会出现缓存与数据库中数据不一致的情况。

在这里插入图片描述

🍀（2）“修改 DB 删除缓存”场景

在很多系统中是没有缓存 warmup 功能的，为了保持缓存与数据库数据的一致性，一般都是在对数据库执行了写操作后，就会删除相应缓存。

在高并发读写请求场景下，若这些请求对 DBMS 中同一个数据的操作既包含写也包含读，且修改后还要删除缓存中相关数据，那么就有可能会出现缓存与数据库中数据不一致的情况。

在这里插入图片描述

🍀（3）解决方案：延迟双删

延迟双删方案是专门针对于“修改 DB 删除缓存”场景的解决方案。但该方案并不能彻底解决数据不一致的状况，其只可能降低发生数据不一致的概率。

延迟双删方案是指，在写操作完毕后会立即执行一次缓存的删除操作，然后再停上一段时间（一般为几秒）后再进行一次删除。而两次删除中间的间隔时长，要大于一次缓存写操作的时长。

在这里插入图片描述

🍀（4）解决方案：队列

以上两种场景中，只所以会出现数据库与缓存中数据不一致，主要是因为对请求的处理出现了并行。只要将请求写入到一个统一的队列，只有处理完一个请求后才可处理下一个请求，即使系统对用户请求的处理串行化，就可以完全解决数据不一致的问题。

🍀（5）解决方案：分布式锁

使用队列的串行化虽然可以解决数据库与缓存中数据不一致，但系统失去了并发性，降低了性能。使用分布式锁可以在不影响并发性的前提下，协调各处理线程间的关系，使数据库与缓存中的数据达成一致性。

只需要对数据库中的这个共享数据的访问通过分布式锁来协调对其的操作访问即可。

后记

在这里插入图片描述
↪️本文下接：XXXX
👉Java全栈学习路线可参考：【Java全栈学习路线】最全的Java学习路线及知识清单，Java自学方向指引，内含最全Java全栈学习技术清单~
👉算法刷题路线可参考：算法刷题路线总结与相关资料分享，内含最详尽的算法刷题路线指南及相关资料分享~