Redis是我们Java开发中，使用频次非常高的一个nosql数据库，数据以key-value键值对的形式存储在内存中。redis的常用使用场景，可以做缓存，分布式锁，自增序列等，使用redis的方式和我们使用数据库的方式差不多，首先我们要在自己的本机电脑或者服务器上安装一个redis的服务器，通过我们的java客户端在程序中进行集成，然后通过客户端完成对redis的增删改查操作。redis的Java客户端类型还是很多的，常见的有jedis, redission,lettuce等，所以我们在集成的时候，我们可以选择直接集成这些原生客户端。但是在springBoot中更常见的方式是集成spring-data-redis，这是spring提供的一个专门用来操作redis的项目，封装了对redis的常用操作，里边主要封装了jedis和lettuce两个客户端。相当于是在他们的基础上加了一层门面。
本篇文章我们就来重点介绍，springBoot通过集成spring-data-redis使用对于redis的常用操作。
由于不涉及到兼容问题，我们就直接在feature/MybatisPlus分支上开发。
2.1 添加依赖
添加redis所需依赖：
完整pom.xml
这里我们直接引入了spring-boot-starter-data-redis这个springBoot本身就已经提供好了的starter, 我们可以点击去看一下这个starter中包含了哪些依赖：
可以发现，里面包含了spring-data-redis和 lettuce-core两个核心包，这就是为什么说我们的spring-boot-starter-data-redis默认使用的就是lettuce这个客户端了。
如果我们想要使用jedis客户端怎么办呢？就需要排除lettuce这个依赖，再引入jedis的相关依赖就可以了。
那么为什么我们只需要通过引入不同的依赖就能让spring-data-redis可以自由切换客户端呢，这其实就涉及到了springBoot的自动化配置原理。我们可以给大家简单讲解一下。
springBoot这个框架之所以可以通过各种starter无缝融合其他技术的一大主要原因就是springBoot本身的自动化配置功能。所谓自动化配置就是springBoot本身已经预先设置好了一些常用框架的整合类。然后通过类似于ConditionOn这样的条件判断注解，去辨别你的项目中是否有相关的类（或配置）了，进而进行相关配置的初始化。
springBoot预设的自动化配置类都位于spring-boot-autoconfigure这个包中，只要我们搭建了springBoot的项目，这个包就会被引入进来。
而这个包下就有一个RedisAutoConfiguration这个类，顾名思义就是Redis的自动化配置。在这个类中，会引入LettuceConnectionConfiguration 和 JedisConnectionConfiguration 两个配置类，分别对应lettuce和jedis两个客户端。
而这个两个类上都是用了ConditionOn注解来进行判断是否加载。
jedis如下；
而由于我们的项目自动引入了lettuce-core，而没有引入jedis相关依赖，所以LettuceConnectionConfiguration这个类的判断成立会被加载，而Jedis的判断不成立，所以不会加载。进而lettuce的配置生效，所以我们在使用的使用， 默认就是lettuce的客户端。
2.2 添加配置
然后我们需要配置连接redis所需的账号密码等信息，这里大家要提前安装好redis,保证我们的本机程序可以连接到我们的redis， 如果不知道redis如何安装，可以参考文章: [Linux系统安装redis6.0.5]
常规配置如下： 在application.yml配置文件中配置 redis的连接信息
如果有其他配置放到一起：
这样我们就可以直接在项目当中操作redis了。如果使用的是集群，那么使用如下配置方式：
但是有的时候我们想要给我们的redis客户端配置上连接池。就像我们连接mysql的时候，也会配置连接池一样，目的就是增加对于数据连接的管理，提升访问的效率，也保证了对资源的合理利用。那么我们如何配置连接池呢，这里大家一定要注意了，很多网上的文章中，介绍的方法可能由于版本太低，都不是特别的准确。 比如很多人使用spring.redis.pool来配置，这个是不对的（不清楚是不是老版本是这样的配置的，但是在springboot-starter-data-redis中这种写法不对）。首先是配置文件，由于我们使用的lettuce客户端，所以配置的时候，在spring.redis下加上lettuce再加上pool来配置，具体如下；
如果使用的是jedis,就把lettuce换成jedis（同时要注意依赖也是要换的）。
但是仅仅这在配置文件中加入，其实连接池是不会生效的。这里大家一定要注意，很多同学在配置文件上加上了这段就以为连接池已经配置好了，其实并没有，还少了最关键的一步，就是要导入一个依赖，不导入的话，这么配置也没有用。
之后，连接池才会生效。我们可以做一个对比。 在导包前后，观察RedisTemplate对象的值就可以看出来。
导入之前：
导入之后：
到入职后，我们的连接池信息才有值，这也印证了我们上面的结论。
具体的配置信息我们可以看一下源代码，源码中使用RedisProperties 这个类来接收redis的配置参数。
2.3 项目中使用
我们的配置工作准备就绪以后，我们就可以在项目中操作redis了，操作的话，使用spring-data-redis中为我们提供的 RedisTemplate 这个类，就可以操作了。我们先举个简单的例子，插入一个键值对（值为string）。
我们在前面的代码中已经通过RedisTemplate成功操作了redis服务器，比如set一个字符串，我们可以使用：
来put一个String类型的键值对。而redis中可以支持 string, list, hash,set, zset五种数据格式，这五种数据格式的常用操作，都在RedisTemplate这个类中进行了封装。 操作string类型就是用opsForValue,操作list类型是用listOps, 操作set类型是用setOps等等。我们可以通过查看RedisTemplate这个类中的源码来了解大致有哪些功能。
而这些功能都在这一个类中，使用起来其实并不是很方便，所有一般情况下，我们都是单独封装一个工具类，来把常用的一些方法进行抽象。操作的时候，直接通过工具类来操作。
大家也可以通过阅读这个工具类，深入了解RedisTemplate的用法。使用的时候，只需要注入这个工具类就可以了。
redis的序列化也是我们在使用RedisTemplate的过程中需要注意的事情。上面的案例中，其实我们并没有特殊设置redis的序列化方式，那么它其实使用的是默认的序列化方式。RedisTemplate这个类的泛型是<String,Object>,也就是他是支持写入Object对象的，那么这个对象采取什么方式序列化存入内存中就是它的序列化方式。
那么什么是redis的序列化呢？就是我们把对象存入到redis中到底以什么方式存储的，可以是二进制数据，可以是xml也可以是json。比如说我们经常会将POJO 到 Redis 中，一般情况下会使用 JSON 方式序列化成字符串，存储到 Redis 中 。
Redis本身提供了一下一种序列化的方式：
如果我们存储的是String类型，默认使用的是StringRedisSerializer 这种序列化方式。如果我们存储的是对象，默认使用的是 JdkSerializationRedisSerializer，也就是Jdk的序列化方式（通过ObjectOutputStream和ObjectInputStream实现，缺点是我们无法直观看到存储的对象内容）。
我们可以根据redis操作的不同数据类型，设置对应的序列化方式。
通过观察RedisTemplate的源码我们就可以看出来，默认使用的是JdkSerializationRedisSerializer. 这种序列化最大的问题就是存入对象后，我们很难直观看到存储的内容，很不方便我们排查问题：
而一般我们最经常使用的对象序列化方式是： Jackson2JsonRedisSerializer
设置序列化方式的主要方法就是我们在配置类中，自己来创建RedisTemplate对象，并在创建的过程中指定对应的序列化方式。
这样使用的时候，就会按照我们设置的json序列化方式进行存储，我们也可以在redis中查看内容的时候方便的查看到属性值。
参考资料：
很多场景中，需要使用分布式事务、分布式锁等技术来保证数据最终一致性。有的时候，我们需要保证某一方法同一时刻只能被一个线程执行。 在单机（单进程）环境中，JAVA提供了很多并发相关API，但在多机（多进程）环境中就无能为力了。
对于分布式锁，最好能够满足以下几点
可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行 这把锁要是一把可重入锁（避免死锁） 这把锁最好是一把阻塞锁 有高可用的获取锁和释放锁功能 获取锁和释放锁的性能要好
分布式锁一般有三种实现方式：1. 数据库乐观锁；2. 基于Redis的分布式锁；3. 基于ZooKeeper的分布式锁。本篇文章主要介绍第二种方式。
一个完美的分布式锁，必须要满足如下四个条件： 1.互斥性。在任意时刻，只有一个客户端能持有锁。 2.不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。 3.具有容错性。只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。 4.解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。
Redis分布式锁原理：
锁的实现主要基于redis的命令
SETNX key value将 key 的值设为 value ，当且仅当 key 不存在。若给定的 key 已经存在，则 SETNX 不做任何动作。SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。
返回值：设置成功，返回 1 。设置失败，返回 0 。
使用完成同步锁的流程及事项如下：
这篇文章中对于Redis中的锁的介绍还是比较全面的。
Redis锁的实现方式很多，到时多多少少都有点问题，相对比较完美的方案是使用lua脚本。最完美的解决方案就是使用Redission这个框架里边的RedissionRedLock。具体实现就不给出了，大家可以按照这个思路去查找相关资料。等到我什么时候有时间和精力了再回来补充一下。
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.mushiming.com/mjsbk/9611.html