Redi6笔记分享（从NoSQL基础到分布式锁的介绍）

本文主要是介绍Redi6笔记分享（从NoSQL基础到分布式锁的介绍），对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

Redis6

1.NoSQL数据库简介

1.1技术发展

题外话：技术的分类

1、解决功能性的问题：Java、Jsp、RDBMS、Tomcat、HTML、Linux、JDBC、SVN

项目的本质无非是增删改查功能，通过这些技术就可以实现CRUD 会产生的问题：需求的变化不断地升级，不断的扩展

2、解决扩展性的问题：Struts、Spring、SpringMVC、Hibernate、Mybatis

用框架就可以解决扩展型的问题。

3、解决性能的问题：NoSQL、Java线程、Hadoop、Nginx、MQ、ElasticSearch

用一些中间件的工具和数据库可以解决项目的性能问题，高并发和多线程

1.1.1web1.0的时代

Web1.0的时代，数据访问量很有限，用一夫当关的高性能的单点服务器可以解决大部分问题。

1.1.2Web2.0的时代

随着Web2.0的时代的到来，用户访问量大幅度提升，同时产生了大量的用户数据。加上后来的智能移动设备的普及，所有的互联网平台都面临了巨大的性能挑战。

缓解Cpu内存的压力，一般采用服务集群的方式来分担服务的请求，Nignx负载均衡，分布式架构

问题就是session该怎么进行存储呢？

解决方案：

1.将session信息存储到客户端，或者是放到cookie中，每次请求都是带着cookie的，但是cookie存储有一个致命缺点，由于cookie存储在客户端，安全性很难有保证

2.session的复制，session复制多个到各个服务器中，缺点是浪费空间，造成冗余。

3.NoSQL数据库存储用户信息，NoSQL不需要进行IO操作，他的数据可以直接存储到内存中，存到内存中读的速度更快。同时NoSQL还可以减少io的读操作，将一些频繁进行查询处理的数据放到缓存数据库中。

1.2NoSQL数据库

1.2.1NoSQL数据库概述

NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，泛指非关系型的数据库。

NoSQL 不依赖业务逻辑方式存储，而以简单的key-value模式存储。因此大大的增加了数据库的扩展能力。

特点：

不遵循SQL标准。
不支持ACID。事务的四个特性，NOSQL是支持事务的
远超于SQL的性能。

1.2.2NoSQL适用场景

对数据高并发的读写
海量数据的读写
对数据高可扩展性的（秒杀功能）

1.2.3NoSQL不适用的场景

需要事务支持
基于sql的结构化查询存储，处理复杂的关系,需要即席查询。

总结：用不着sql的和用了sql也不行的情况，请考虑用NoSql

1.2.4常用的NoSQL

1.3.1行式数据库

按行存储

1.3.2列式数据库

按列存储

2.Redis概述与安装

Redis是一个开源的key-value存储系统。

和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。

这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。

在此基础上，Redis支持各种不同方式的排序。

与memcached一样，为了保证效率，数据都是缓存在内存中。

区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件。

并且在此基础上实现了master-slave(主从)同步。

2.1Redis的应用场景

2.1.1配合关系型数据库做高速缓存

高频次，热门访问的数据，降低数据库IO
分布式架构，做session共享

2.1.2多样的数据结构存储持久化数据

2.2 Redis安装

2.2.1安装版本

6.2.1 for Linux（redis-6.2.1.tar.gz）
不用考虑在windows环境下对Redis的支持

2.6Redis相关知识介绍

redis默认有16个数据库，下标从0-15，使用select i 表示切换到第i个数据库

dbsize可以查看

memcached和redis的区别 memcached是串行执行+多线程+锁机制的形式

而Redis是单线程 + 多路IO复用的形式实现的。

3.Redis常用五大数据类型

Redis命令中心（Redis commands） -- Redis中国用户组（CRUG）： Redis常见数据类型操作命令

3.1Redis键（Key）

keys *查看当前库所有key (匹配：keys *1)

exists key判断某个key是否存在

type key 查看你的key是什么类型

del key 删除指定的key数据

unlink key 根据value选择非阻塞删除非阻塞：仅将keys从keyspace元数据中删除，真正的删除的会在后续异步操作

expire key 10 ：设置key的过期时间为10s，10s后key-v将不复存在

ttl key ：查看key多久过期， -1 为永不过期，-2为已过期

select命令切换数据库

dbsize查看当前数据库的key的数量

flushdb清空当前库

flushall通杀全部库

3.2Redis字符串（String）

3.2.1简介

String是Redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。

String类型是二进制安全的。意味着Redis的string可以包含任何数据。比如jpg图片或者序列化的对象。

String类型是Redis最基本的数据类型，一个Redis中字符串value最多可以是512M

3.2.2String常用命令

set <key><value>添加键值对

*NX：当数据库中key不存在时，可以将key-value添加数据库

*XX：当数据库中key存在时，可以将key-value添加数据库，与NX参数互斥

*EX：key的超时秒数

*PX：key的超时毫秒数，与EX互斥

get <key>查询对应键值

append <key><value>将给定的<value> 追加到原值的末尾

strlen <key>获得值的长度

setnx <key><value> 只有在 key 不存在时设置 key 的值

incr <key> 将 key 中储存的数字值增1 只能对数字值操作，如果为空，新增值为1

decr <key> 将 key 中储存的数字值减1 只能对数字值操作，如果为空，新增值为-1

incrby / decrby <key><步长>将 key 中储存的数字值增减。自定义步长。

在用incr key的时候有一个特点是原子性操作，所谓原子性操作是指不会被线程调度机制所打断的操作，这种操作点开始就会一直运行到结束，中间不会有任何的context switch （切换线程）

（1）在单线程中，能够在单条指令中完成的操作都可以认为是"原子操作"，因为中断只能发生于指令之间。

（2）在多线程中，不能被其它进程（线程）打断的操作就叫原子操作。

Redis单命令的原子性主要得益于Redis的单线程。

mset <key1><value1><key2><value2> .....

同时设置一个或多个 key-value对

mget <key1><key2><key3> .....

同时获取一个或多个 value

msetnx <key1><value1><key2><value2> .... 同时设置一个或多个 key-value 对，当且仅当所有给定 key 都不存在。这有这些要设置的key都不存在才可以成功。

getrange <key><起始位置><结束位置>

获得值的范围，类似java中的substring，前包，后包

setrange <key><起始位置><value>

用 <value> 覆写<key>所储存的字符串值，从<起始位置>开始(索引从0**开始**)。

setex <过期时间>

设置键值的同时，设置过期时间，单位秒。

getset <key><value>

以新换旧，设置了新值同时获得旧值。

3.2.3String底层的数据结构

String的数据结构为简单动态字符串(Simple Dynamic String,缩写SDS)。是可以修改的字符串，内部结构实现上类似于Java的ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配.

如图中所示，内部为当前字符串实际分配的空间capacity一般要高于实际字符串长度len。当字符串长度小于1M时，扩容都是加倍现有的空间，如果超过1M，扩容时一次只会多扩1M的空间。需要注意的是字符串最大长度为512M。

3.3Redis列表（List）

list为单键多值

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。

3.3.1常用命令

lpush/rpush <key><value1><value2><value3> .... 从左边/右边插入一个或多个值。（即头插和尾插法）

lpop/rpop <key>从左边/右边吐出一个值。值在键在，值光键亡。

rpoplpush <key1><key2> 从<key1>列表右边吐出一个值，插到<key2>列表左边。

lrange <key><start><stop>

按照索引下标获得元素(从左到右)

lrange mylist 0 -1 0左边第一个，-1右边第一个，（0-1表示获取所有）

lindex <key><index>按照索引下标获得元素(从左到右)

llen <key>获得列表长度

linsert <key> before <value><newvalue>在<value>的后面插入<newvalue>插入值

lrem <key><n><value>从左边删除n个value(从左到右)

lset<key><index><value>将列表key下标为index的值替换成value

3.3.3List的数据结构

List的数据结构为快速链表quickList。

首先在列表元素较少的情况下会使用一块连续的内存存储，这个结构是ziplist，也即是压缩列表。

它将所有的元素紧挨着一起存储，分配的是一块连续的内存。

当数据量比较多的时候才会改成quicklist。

因为普通的链表需要的附加指针空间太大，会比较浪费空间。比如这个列表里存的只是int类型的数据，结构上还需要两个额外的指针prev和next。

Redis将链表和ziplist结合起来组成了quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。

3.4Redis集合（set）

无重复，无序

set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。

Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表，所以添加，删除，查找的复杂度都是O(1)。

一个算法，随着数据的增加，执行时间的长短，如果是O(1)，数据增加，查找数据的时间不变

3.3.1Set的命令

sadd <key><value1><value2> .....

将一个或多个 member 元素加入到集合 key 中，已经存在的 member 元素将被忽略

smembers <key>取出该集合的所有值。

sismember <key><value>判断集合<key>是否为含有该<value>值，有1，没有0

scard<key>返回该集合的元素个数。

srem <key><value1><value2> .... 删除集合中的某个元素。

spop <key>随机从该集合中吐出一个值。

srandmember <key><n>随机从该集合中取出n个值。不会从集合中删除。

smove <source><destination>value把集合中一个值从一个集合移动到另一个集合

sinter <key1><key2>返回两个集合的交集元素。

sunion <key1><key2>返回两个集合的并集元素。

sdiff <key1><key2>返回两个集合的差集元素(key1中的，不包含key2中的)

3.4.2Set底层数据结构

Set数据结构是dict字典，字典是用哈希表实现的。

Java中HashSet的内部实现使用的是HashMap，只不过所有的value都指向同一个对象。Redis的set结构也是一样，它的内部也使用hash结构，所有的value都指向同一个内部值。

3.5Redis哈希（hash）

3.5.1简介

Redis hash 是一个键值对集合。

Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。

类似Java里面的Map<String,Object

存储对象实例：

第一种存储方式, k-v实现存储

 user:{id=1,name=zhangsan,age=20} #这是存在问题的：
 #如果user的年龄每年都需要变化，那么user的数据就得都取出来，取出来之后先通过json变为对象，变为对象之后，将age值改为新的结果，然后再将对象转为JSON存入redis中

第二种存储方式：k-v实现

 user:id 1
 user:name zhangsan
 user:age 20
 #优点例如只修改一个属性，只需要将一段的数据取出来即可
 #缺点，存储的数据太分散了，存储很混乱

第三种：hash的存储方式

 user 为key，value也是映射关系
 value : {id = 1,name = zhangsan, age = 20}

通过 key(用户ID) + field(属性标签) 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。

3.5.2常用命令

hset <key><field><value> 给<key>集合中的 <field>键赋值<value>

hget <key1><field> 从<key1>集合<field>取出 value

hmset <key1><field1><value1><field2><value2>... 批量设置hash的值

hexists<key1><field> 查看哈希表 key 中，给定域 field 是否存在。

hkeys <key> 列出该hash集合的所有field

hvals <key> 列出该hash集合的所有value

hincrby <key><field><increment> 为哈希表 key 中的域 field 的值加上增量 1 -1

hsetnx <key><field><value> 将哈希表 key 中的域 field 的值设置为 value ，当且仅当域 field 不存在 .

3.5.3Hash的数据结构

Hash类型对应的数据结构是两种：ziplist（压缩列表），hashtable（哈希表）。当field-value长度较短且个数较少时，使用ziplist，否则使用hashtable。

zipList（压缩列表）：

Redis源码分析-压缩列表ziplist_weixin_33800463的博客-CSDN博客

3.6Redis有序集合（Zset）

3.6.1有序集合简介

Redis有序集合zset与普通集合set非常相似，是一个没有重复元素的字符串集合。

不同之处是有序集合的每个成员都关联了一个评分（score）,这个评分（score）被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的，但是评分可以是重复了。

因为元素是有序的, 所以你也可以很快的根据评分（score）或者次序（position）来获取一个范围的元素。

访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。

3.6.2常用命令

zadd <key><score1><value1><score2><value2>…

将一个或多个 member 元素及其 score 值加入到有序集 key 当中。

zrange [WITHSCORES]

返回有序集 key 中，下标在<start><stop>之间的元素

带WITHSCORES，可以让分数一起和值返回到结果集。

zrangebyscore key minmax [withscores] [limit offset count]

返回有序集 key 中，所有 score 值介于 min 和 max 之间(包括等于 min 或 max )的成员。有序集成员按 score 值递增(从小到大)次序排列。

zrevrangebyscore key maxmin [withscores] [limit offset count]

同上，改为从大到小排列。

zincrby <key><increment><value> 为元素的score加上增量

zrem <key><value>删除该集合下，指定值的元素

zcount <key><min><max>统计该集合，分数区间内的元素个数

zrank <key><value>返回该值在集合中的排名，从0开始。

3.6.3Zset底层的数据结构

Zset是Redis提供的一个特别的数据结构，一方面它等价于Java的数据结构MAp<String,Double>,可以给每一个元素value赋予一个权重score，另一方面它又类似于TreeSet,它内部的元素按照权重score排序，得到每个元素的名词，可以通过score的范围来获取列表。

zset底层使用了两个数据结构

①hash，hash的作用是关联元素的value值和权重score，保障元素value的唯一性，可以通过value找到相关的score值

②跳跃表（跳表），跳跃表的目的在于给元素value排序，根据score的范围获取元素列表。

3.6.4跳跃表的介绍

1.简介

有序集合在生活中比较常见，例如根据成绩对学生排名，根据得分对玩家排名等。对于有序集合的底层实现，可以用数组、平衡树、链表等。数组不便元素的插入、删除；平衡树或红黑树虽然效率高但结构复杂；链表查询需要遍历所有效率低。Redis采用的是跳跃表。跳跃表效率堪比红黑树，实现远比红黑树简单。

2.例子：对比普通的有序链表和跳表，查找出指定元素51

有序链表：

要查找值为51的元素，需要从第一个元素开始依次查找、比较才能找到。共需要6次比较。

跳跃表：

从第2层开始，1节点比51节点小，向后比较。

21节点比51节点小，继续向后比较，后面就是NULL了，所以从21节点向下到第1层

在第1层，41节点比51节点小，继续向后，61节点比51节点大，所以从41向下

在第0层，51节点为要查找的节点，节点被找到，共查找4次

3.7跳跃表面试知识点

通过增加索引层数和个数来减少搜索的时间复杂度，加快查询的效率。用空间来交换时间。

由于跳表除了原链表之后的各层级索引，只保存了前后指针和关键值，不会存在大对象的存储，所以在具体研发中基本不必特别在意空间带来的影响。

4.Redis的配置文件详解

4.1Units单位

配置大小单位,开头定义了一些基本的度量单位，只支持bytes（字节类型），不支持bit

大小写不敏感

4.2INCLUDES包含

类似jsp中的include，多实例的情况可以把公用的配置文件提取出来

4.3###网络相关配置###

在文件中的bind 127.0.0.1 - : :1 这个就是限制了只能在本身主机上进行访问

默认情况bind=127.0.0.1只能接受本机的访问请求

不写的情况下，无限制接受任何ip地址的访问

如果开启了protected-mode，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应

protected-mode no之后，就没有了保护模式，其他ip地址主机就可以访问到该redis环境了

4.3.3Port 的端口默认是6379

4.3.4tcp - backlog

设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。

在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。

注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值（128），所以需要确认增大/proc/sys/net/core/somaxconn和/proc/sys/net/ipv4/tcp_max_syn_backlog（128）两个值来达到想要的效果

4.3.4timeout

一个空闲的客户端维持多少秒会关闭，0表示关闭该功能。即永不关闭。

4.3.5tcp-keepalive

对访问客户端的一种心跳检测，每个n秒检测一次。

单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60

4.4###GENERAL通用###

4.4.1daemonize

是否为后台进程，设置为yes

守护进程，后台启动

4.4.2datebase

设置数据库的大小

4.5###secret密码###

4.5.1设置密码

访问密码的查看、设置和取消

在命令中设置密码，只是临时的。重启redis服务器，密码就还原了。

永久设置，需要再配置文件中进行设置。

4.6####LIMITS限制####

4.6.1maxclients最大客户端连接数

设置redis同时可以与多少个客户端进行连接。默认情况下的最大连接数为10000个客户端

如果超过了设置的限制，redis将会拒绝新的连接请求，并且向这些请求发送"max number of clients reached"作为回应

4.6.2maxmemory

建议必须设置，否则将内存占满会造成服务器宕机

设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定

如果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等

5.Redis的订阅与发布

5.1什么是订阅和发布

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。

Redis 客户端可以订阅任意数量的频道。

5.2Redis的发布和订阅

1.客户端可以订阅频道如下图：

2.当这个频道发布消息之后，消息就会发送给订阅频道的客户端。

5.3发布订阅命令行实现

1.打开一个客户端订阅channel1

 subscribe channel1
 //订阅一个频道

2.向channel1中发布消息

 publish channel1 hello

3.打开第一个客户端就可以看到发送的消息

注：发布的消息没有持久化，如果在订阅的客户端收不到hello，只能收到订阅后发布的消息。

6.Redis的新数据类型

6.1Bitmaps（位操作记录）

bit有位的意思，所以该数据结构主要就是进行位操作

简介：

现代计算机用二进制（位）作为信息的基础单位， 1个字节等于8位，例如“abc”字符串是由3个字节组成，但实际在计算机存储时将其用二进制表示， “abc”分别对应的ASCII码分别是97、 98、 99，对应的二进制分别是01100001、 01100010和01100011，如下图

如果可以合理的使用操作位就可以有效的提高内存的使用率和开发效率

Redis提供了Bitmaps这个数据类型可以实现对位的操作：

① Bitmaps本身不是一种数据类型，实际上它就是字符串（key-value），它是专门进行位操作的字符串

②Bitmaps单独提供了一套命令，所以在Redis中使用Bitmaps和使用字符串的方法不太相同。可以把Bitmaps想象成一个以位为单位的数组，数组的每个单元只能存储0和1，数组的下标在Bitmaps中叫做偏移量。

如下图所示

6.1.2命令

1.setbit

格式：

 setbit<key><offset><value>   ##设置Bitmaps中某个偏移量的值（0或1）,offset：偏移量从0开始

实例：

每个独立用户是否访问过网站存放在Bitmaps中，将访问的用户记做1，没有访问的用户记做0，用偏移量作为用户的id。

设置键的第offset个位的值（从0算起），假设现在有20个用户，userid=1， 6， 11， 15， 19的用户对网站进行了访问，那么当前Bitmaps初始化结果如图

unique:users:20211106代表2020-11-06这天的独立访问用户的Bitmaps

很多应用的用户id以一个指定数字（例如10000）开头，直接将用户id和Bitmaps的偏移量对应势必会造成一定的浪费，通常的做法是每次做setbit操作时将用户id减去这个指定数字。

在第一次初始化Bitmaps时，假如偏移量非常大，那么整个初始化过程执行会比较慢，可能会造成Redis的阻塞。

2.getbit

 getbit<key><offset>  ##获取Bitmaps中某个偏移量的值

3.bitcount

统计字符串被设置为1的bit数。一般情况下，给定的整个字符串都会被进行计数，通过指定额外的 start 或 end 参数，可以让计数只在特定的位上进行。start 和 end 参数的设置，都可以使用负数值：比如 -1 表示最后一个位，而 -2 表示倒数第二个位，start、end 是指bit组的字节的下标数，二者皆包含。

 bitcount<key>[start end]  ##统计字符串从start字节到end字节比特值为1的数量

4.bitop

 bitop  and(or/not/xor) <destkey> [key…] 
 #bitop是一个复合操作， 它可以做多个Bitmaps的and（交集） 、 or（并集） 、 not（非） 、 xor（异或） 操作并将结果保存在destkey中。

6.1.3Bitmaps和set的对比

1.bitmaps比set更加的节省空间

2.bitmaps也不是万金油，假如该网站每日的活跃度很低，例如只有10万，那么bitmaps的优势就体现不出了。

6.2HyperLogLog（处理基数问题）

6.2.1简介

在工作当中，我们经常会遇到与统计相关的功能需求，比如统计网站PV（PageView页面访问量）,可以使用Redis的incr、incrby轻松实现。

但像UV（UniqueVisitor，独立访客）、独立IP数、搜索记录数等需要去重和计数的问题如何解决？这种求集合中不重复元素个数的问题称为基数问题。例如同一个用户多次访问网站只需要记录一次，同一个IP访问也是只需要记录一次。

基数问题：比如数据集{1,3,5,7,5,7,8}，这个数据的基数为{1,3,5,7,8}，基数是统计不重复的元素

解决基数问题的办法：

①MySQL表中，使用distinct count 计算出不重复的个数

②使用Redis提供的hash，set，bitmaps等数据结构处理。

但是通过以上方法解决后，随着数据的不断增加，将会导致占用的内存空间越来越大，对于非常大的数据集是不可行的。所以Redis提出了HyperLogLog来做基数统计的算法。可以通过更少的空间存储更多的值。

6.2.2命令

1.pfadd

 pfadd <key>< element> [element ...]   #添加指定元素到 HyperLogLog 中

实例:

将所有元素添加到指定HyperLogLog数据结构中。如果执行命令后HLL估计的近似基数发生变化，则返回1，否则返回0。

2.pfcount

 pfcount<key> [key ...] #计算HLL的近似基数，可以计算多个HLL

3.pfmerge

 pfmerge<destkey><sourcekey> [sourcekey ...]  #将一个或多个HLL合并后的结果存

6.3Geospatial（地理信息问题）

6.3.1简介

Redis 3.2 中增加了对GEO类型的支持。GEO，Geographic，地理信息的缩写。该类型，就是元素的2维坐标，在地图上就是经纬度。redis基于该类型，提供了经纬度设置，查询，范围查询，距离查询，经纬度Hash等常见操作。

6.3.2命令

1.geoadd

 geoadd <key> <longitude> <latitude> <member> [longitude latitude member...]   #添加地理位置（经度，纬度，名称）

2.geopos

 geopos  <key><member> [member...]   #获得指定地区的坐标值

3.geodist

 geodist <key> <member1> <member2>  [m|km|ft|mi ]  #获取两个位置之间的直线距离,后面加的参数是单位值，返回的将会按照指定的单位进行返回

4.georadius

 georadius<key>< longitude><latitude>radius  m|km|ft|mi   #以给定的经纬度为中心，找出某一半径内的元素

7.Redis_Jedis_测试

7.1Jedis测试所需要的的jar包

maven文件,导入所需要的jar包

 <dependency>
 <groupId>redis.clients</groupId>
 <artifactId>jedis</artifactId>
 <version>3.2.0</version>
 </dependency>

7.2Jedis连接的注意事项

禁用Linux的防火墙：Linux(CentOS7)里执行命令
systemctl stop/disable firewalld.service
redis.conf中注释掉bind 127.0.0.1 ,然后 protected-mode no

7.3Jedis的常用操作

7.3.1创建动态工程

7.3.2创建测试类

 import redis.clients.jedis.Jedis;
 public class Demo01 {
     public static void main(String[] args) {
         Jedis jedis = new Jedis("192.168.137.3",6379);
         String pong = jedis.ping();
         System.out.println("连接成功："+pong);
         jedis.close();
     }
 }

7.4.1测试相关数据类型

Jedis-API

Key

 @Test//获取所有的key值
 public void demo1(){
     Jedis jedis = new Jedis("192.168.112.130",6379);
     Set<String> keys = jedis.keys("*");
     for(String key : keys){
         System.out.println(key);
     }
     jedis.set("k1", "v1");
     jedis.set("k2", "v2");
     jedis.set("k3", "v3");
     Set<String> keys = jedis.keys("*");
     System.out.println(keys.size());
     for (String key : keys) {
         System.out.println(key);
     }
     System.out.println(jedis.exists("k1"));
     System.out.println(jedis.ttl("k1"));                
     System.out.println(jedis.get("k1"));
 
 }

String

 jedis.mset("str1","v1","str2","v2","str3","v3");//创建多个

List

 @Test
 public void demo2(){
     jedis.lpush("key1","lucy","mary","jack");
     List<String> values = jedis.lrange("key1",0,-1);
 }

Set

 @Test
 public void demo3(){
     jedis.sadd("orders", "order01");
     jedis.sadd("orders", "order02");
     jedis.sadd("orders", "order03");
     jedis.sadd("orders", "order04");
     Set<String> smembers = jedis.smembers("orders");
     for (String order : smembers) {
     System.out.println(order);
     }
     jedis.srem("orders", "order02");
 
 }

hash

 jedis.hset("user","age","20");
 String hget = jedis.hget("user","age");

Zset

 jedis.zadd("zset01",100d,"z3");
 jedis.zadd("zset01",90d,"i4");
 Set<String> zrange = jedis.zrange("zset01",0,-1);//获取全部的zset值

8.Redis_Jedis_实例

8.1完成一个手机验证码的功能

要求

①输入手机号，点击发送后随机生成6位数字码，2分钟内有效

②输入验证码，点击验证，返回成功或失败

③每个手机号每天只能输入三次

对应的基本步骤：

1.生成随机的6位数字 Random函数

     //1.生成六位数字验证码
      public static String getCode(){
         Random random = new Random();
         String code = "";
         for(int i = 0; i < 6; i++){
             int rand = random.nextInt(10);
 
             code += rand;
         }
         return code;
     }

2.验证码在2分钟内有效，将验证码存储到redis中设置一下过期时间即可。并且设置验证码的发送次数： redis 用incr操作当数量大于2的时候不能再发送。

 public static void putCode(String phone){
     Jedis jedis = new Jedis("192.168.112.130",6379);
     
     String countOfPut = "VerifyCode" + phone +":count";//用作后面设置key-vlaue的key值
     String codeKey = "VerifyCode" + phone + "code";
     String count = jedis.get(countOfPut);//获取发送次数
     if(count == null){//第一次发送
          jedis.setex(countOfPut,24*60*60,"1");//第一次设置这个值为1
     }else if(Integer.parseInt(count) <= 2){
         jedis.incr(countOfPut);//已经申请验证码的次数+1
     }else if(Integer.parseInt(count) > 2){
         System.out.println("发送次数已达上限");
     }
         String vCode = getCode();
         jedis.setex(codeKey,120,vCode);
 
         jedis.close();
 }

3.判断输入的数字和验证码是否一致：从redis中获取验证码进行校对。

9.SpringBoot整合Redis

Spring Boot整合Redis非常简单，只需要按如下步骤整合即可

9.1整合步骤

1、在pom.xml文件中引入redis相关依赖

 <!-- redis -->
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-data-redis</artifactId>
 </dependency>
 
 <!-- spring2.X集成redis所需common-pool2-->
 <dependency>
 <groupId>org.apache.commons</groupId>
 <artifactId>commons-pool2</artifactId>
 <version>2.6.0</version>
 </dependency>

2、 application.properties配置redis配置

 #Redis服务器地址
 spring.redis.host=192.168.112.130
 #Redis服务器连接端口
 spring.redis.port=6379
 #Redis数据库索引（默认为0）
 spring.redis.database= 0
 #连接超时时间（毫秒）
 spring.redis.timeout=1800000
 #连接池最大连接数（使用负值表示没有限制）
 spring.redis.lettuce.pool.max-active=20
 #最大阻塞等待时间(负数表示没限制)
 spring.redis.lettuce.pool.max-wait=-1
 #连接池中的最大空闲连接
 spring.redis.lettuce.pool.max-idle=5
 #连接池中的最小空闲连接
 spring.redis.lettuce.pool.min-idle=0

3、添加redis配置类

 @EnableCaching
 @Configuration
 public class RedisConfig extends CachingConfigurerSupport {
 
     @Bean
     public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory) {
         RedisTemplate<String, Object> template = new RedisTemplate<>();
         RedisSerializer<String> redisSerializer = new StringRedisSerializer();
         Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
         ObjectMapper om = new ObjectMapper();
         om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
         om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
         jackson2JsonRedisSerializer.setObjectMapper(om);
         template.setConnectionFactory(factory);
 //key序列化方式
         template.setKeySerializer(redisSerializer);
 //value序列化
         template.setValueSerializer(jackson2JsonRedisSerializer);
 //value hashmap序列化
         template.setHashValueSerializer(jackson2JsonRedisSerializer);
         return template;
     }
     @Bean
     public CacheManager cacheManager(RedisConnectionFactory factory) {
         RedisSerializer<String> redisSerializer = new StringRedisSerializer();
         Jackson2JsonRedisSerializer jackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);
 //解决查询缓存转换异常的问题
         ObjectMapper om = new ObjectMapper();
         om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
         om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
         jackson2JsonRedisSerializer.setObjectMapper(om);
 // 配置序列化（解决乱码的问题）,过期时间600秒
         RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
                 .entryTtl(Duration.ofSeconds(600))
                 .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(redisSerializer))
                 .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(jackson2JsonRedisSerializer))
                 .disableCachingNullValues();
         RedisCacheManager cacheManager = RedisCacheManager.builder(factory)
                 .cacheDefaults(config)
                 .build();
         return cacheManager;
     }
 }

10.Redis事务，锁机制和秒杀的实现

10.1Redis事务定义

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis事务的主要作用就是串联多个命令防止别的命令插队。

10.21Multi、Exec、discard（组队，执行，解散）

从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。组队的过程中可以通过discard来放弃组队。

案例演示

代码顺序

 multi

在接下来的操作都会作为一个事务来等待执行知道执行了exec命令事务里的代码才会执行

dicard就会放弃组队，让当前事务里的全部不执行

10.3事务的错误处理

组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。

如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

10.4产生事务的原因

10.5事务的冲突问题

例子：

你有一个账号，三个人使用你的账号对你的金额进行操作

一个请求要-8000，第二个请求-5000，第三个请求是-1000

这个过程的先后顺序执行之后可能导致最终的余额为-4000

在多个操作之间并没有添加事务，对数据都同时产生影响

10.5.1解决方法

Redis中主要通过锁的机制来解决事务冲突的问题，锁则一般分成为悲观锁和乐观锁两种

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。通过添加版本号实现乐观锁。

当一个任务执行完之后，会对版本号进行更改，下一次操作的时候会对版本号先进行判断是否相同，相同的情况下才会进行后面的操作。

10.5.2WATCH key [key .......]

相当于监听器

在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key被其他命令所改动，那么事务将被打断。

实例

打开两个终端，对同一个key值进行修改

终端一：

 set balance 100
 watch balance
 multi
 incrby balance 10
 exec
 ->ok        #执行成功

终端二：

 watch balance
 multi
 incrby balance 20
 exec
 ->nil       #执行失败

unwatch

取消 WATCH 命令对所有 key 的监视。

如果在执行 WATCH 命令之后，EXEC 命令或DISCARD 命令先被执行了的话，那么就不需要再执行UNWATCH 了。

10.6Redis事务的三大特性

1.单独的隔离操作

事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

2.没有隔离级别的概念

队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行

3.不保证原子性

事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。如果在组队过程中有一个失败那么就都不会成功，但是如果组队完成后在执行阶段出现错误，有那个失败就失败不影响后续的操作。

11.Redis事务的秒杀功能案例

11.1解决计数器和人员记录的事务操作

事务里秒杀成功的操作其实就是库存数量-1和购买者数量+1

11.2基本的前端代码和后端servlet代码

前端页面代码

 <%@ page language="java" contentType="text/html; charset=UTF-8"
     pageEncoding="UTF-8"%>
 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
 <title>Insert title here</title>
 </head>
 <body>
 <h1>iPhone 13 Pro !!!  1元秒杀！！！
 </h1>
 
 
 <form id="msform" action="${pageContext.request.contextPath}/doseckill" enctype="application/x-www-form-urlencoded">
     <input type="hidden" id="prodid" name="prodid" value="0101">
     <input type="button"  id="miaosha_btn" name="seckill_btn" value="秒杀点我"/>
 </form>
 
 </body>
 <script  type="text/javascript" src="${pageContext.request.contextPath}/script/jquery/jquery-3.1.0.js"></script>
 <script  type="text/javascript">
 $(function(){
     $("#miaosha_btn").click(function(){  
         var url=$("#msform").attr("action");
          $.post(url,$("#msform").serialize(),function(data){
             if(data=="false"){
                 alert("抢光了" );
                 $("#miaosha_btn").attr("disabled",true);
             }
         } );    
     })
 })
 </script>
 </html>

后端servlet代码：

 public class SecKillServlet extends HttpServlet {
     private static final long serialVersionUID = 1L;
 
     public SecKillServlet() {
         super();
     }
 
     protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 
         String userid = new Random().nextInt(50000) +"" ;
         String prodid =request.getParameter("prodid");
         
         //boolean isSuccess=SecKill_redis.doSecKill(userid,prodid);
         boolean isSuccess= SecKill_redisByScript.doSecKill(userid,prodid);
         response.getWriter().print(isSuccess);
     }
 
 }

redis代码

 import java.io.IOException;
 import java.util.HashSet;
 import java.util.List;
 import java.util.Set;
 import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
 import org.slf4j.LoggerFactory;
 import ch.qos.logback.core.rolling.helper.IntegerTokenConverter;
 import redis.clients.jedis.HostAndPort;
 import redis.clients.jedis.Jedis;
 import redis.clients.jedis.JedisCluster;
 import redis.clients.jedis.JedisPool;
 import redis.clients.jedis.JedisPoolConfig;
 import redis.clients.jedis.ShardedJedisPool;
 import redis.clients.jedis.Transaction;
 /**
  *
  */
 public class SecKill_redis {
 
     public static void main(String[] args) {
         Jedis jedis =new Jedis("192.168.44.168",6379);
         System.out.println(jedis.ping());
         jedis.close();
     }
 
     //秒杀过程
     public static boolean doSecKill(String uid,String prodid) throws IOException {
         //1 uid和prodid非空判断
         if(uid == null || prodid == null) {
             return false;
         }
 
         //2 连接redis
         //Jedis jedis = new Jedis("192.168.44.168",6379);
         //通过连接池得到jedis对象
         JedisPool jedisPoolInstance = JedisPoolUtil.getJedisPoolInstance();
         Jedis jedis = jedisPoolInstance.getResource();
 
         //3 拼接key
         // 3.1 库存key
         String kcKey = "sk:"+prodid+":qt";//对应在redis数据库中的key为这个，value为String类型的个数
         // 3.2 秒杀成功用户key
         String userKey = "sk:"+prodid+":user";//对应的redis中的key为userKey，value为用户的id——> uid
 
         //监视库存
         jedis.watch(kcKey);
 
         //4 获取库存，如果库存null，秒杀还没有开始
         String kc = jedis.get(kcKey);
         if(kc == null) {
             System.out.println("秒杀还没有开始，请等待");
             jedis.close();
             return false;
         }
 
         // 5 判断用户是否重复秒杀操作
         if(jedis.sismember(userKey, uid)) {
             System.out.println("已经秒杀成功了，不能重复秒杀");
             jedis.close();
             return false;
         }
 
         //6 判断如果商品数量，库存数量小于1，秒杀结束
         if(Integer.parseInt(kc)<=0) {
             System.out.println("秒杀已经结束了");
             jedis.close();
             return false;
         }
 
         //7 秒杀过程
         //使用事务进行操作
         Transaction multi = jedis.multi();
 
         //组队操作
         multi.decr(kcKey);
         multi.sadd(userKey,uid);
 
         //执行
         List<Object> results = multi.exec();
 
         if(results == null || results.size()==0) {
             System.out.println("秒杀失败了....");
             jedis.close();
             return false;
         }
 
         //7.1 库存-1
         //jedis.decr(kcKey);
         //7.2 把秒杀成功用户添加清单里面
         //jedis.sadd(userKey,uid);
 
         System.out.println("秒杀成功了..");
         jedis.close();
         return true;
     }
 }

测试就是打开网页进行测试即可

 #设置商品的初始数量
 set sk:0101:qt 10
 smembers sk:0101:user #获取set集合的内容

11.3模拟并发情况下的秒杀情况

模拟多请求并发的效果

使用ab工具模拟并发情况下的测试

CentOS6默认已安装

CentOS7需要手动安装

有网络状态下：yum install httpd-tools

无网络状态下：

（1）进入cd /run/media/root/CentOS 7 x86_64/Packages（路径跟centos6不同）

（2）顺序安装

apr-1.4.8-3.el7.x86_64.rpm

apr-util-1.5.2-6.el7.x86_64.rpm

httpd-tools-2.4.6-67.el7.centos.x86_64.rpm

并发测试过程

vim postfile 模拟表单提交参数,以&符号结尾;存放当前目录。

 ab -n 1000 -c 100 -p ~/postfile -t 'application/x-www-form-urlencoded' http://192.168.140.1:8080/seckill/doseckill #再加上路径
 
 -n 1000 #表示有1000个请求
 -c 100 #有100个并发
 -p postfile #从postfile文件中获取post提交的参数
 
 vi postfile #添加postfile文件，文件内写入参数并且通过&连接多个参数，最后一个后面要有一个&
 prodid = 0101&

测试结果：

出现了负数库存和在秒杀结束后再次秒杀成功的问题。

11.4多并发暴露的问

11.4.1超卖问题

由于并发的操作，使得数据在一个操作内更改另一个还没有改变使得出现问题。

解决办法是利用乐观锁来解决超卖问题，在jedis中调用watch方法监视库存key值的变化，之后将最终秒杀的过程放到一个事务中去

 jedis.watch(kcKey);//
 Transaction multi = jedis.multi();   //开启一个事务的方法multi，返回的是一个事务对象
 //组队操作
 multi.decr(kcKey);
 multi.sadd(userKey,uid);
 //执行
 List<Object> results = multi.exec(); //执行事务的结果如果为null，则说明事务执行失败

11.4.2连接超时问题

在继续增加并发的大小之后，发现连接有限了，我们采用数据库连接池解决这个问题

节省每次连接redis服务带来的消耗，把连接好的实例反复利用。

通过参数管理连接的行为

代码见项目中

 package com.atguigu;
 
 import redis.clients.jedis.Jedis;
 import redis.clients.jedis.JedisPool;
 import redis.clients.jedis.JedisPoolConfig;
 
 public class JedisPoolUtil {
     private static volatile JedisPool jedisPool = null;
 
     private JedisPoolUtil() {
     }
 
     public static JedisPool getJedisPoolInstance() {
         if (null == jedisPool) {
             synchronized (JedisPoolUtil.class) {
                 if (null == jedisPool) {
                     JedisPoolConfig poolConfig = new JedisPoolConfig();
                     poolConfig.setMaxTotal(200);//连接池最大连接数
                     poolConfig.setMaxIdle(32);//
                     poolConfig.setMaxWaitMillis(100*1000);//最大等待时间
                     poolConfig.setBlockWhenExhausted(true);
                     poolConfig.setTestOnBorrow(true);  //测试连接状态 ping  PONG
                  
                     jedisPool = new JedisPool(poolConfig, "192.168.44.168", 6379, 60000 );
                     //超时时间，超过指定时间不再提供服务。
                 }
             }
         }
         return jedisPool;
     }
 
     public static void release(JedisPool jedisPool, Jedis jedis) {
         if (null != jedis) {
             jedisPool.returnResource(jedis);
         }
     }
 }

11.4.3解决库存遗留问题

在增加库存和并发数量之后，我们发现有的时库存还是有的却秒杀失败，这是因为乐观锁的缺点，乐观锁只负责了安全，没有管你商品会不会卖完，所以可能在更改了版本号之后导致一些列操作无法成功，需要改进。

而redis并没有提供悲观锁的方法，而且悲观锁的并发度太低，任务可能会一直等待。

LUA（露阿）脚本语言

Lua 是一个小巧的脚本语言，Lua脚本可以很容易的被C/C++ 代码调用，也可以反过来调用C/C++的函数，Lua并没有提供强大的库，一个完整的Lua解释器不过200k，所以Lua不适合作为开发独立应用程序的语言，而是作为嵌入式脚本语言。

很多应用程序、游戏使用LUA作为自己的嵌入式脚本语言，以此来实现可配置性、可扩展性。

这其中包括魔兽争霸地图、魔兽世界、博德之门、愤怒的小鸟等众多游戏插件或外挂。

 local userid=KEYS[1]; 
 local prodid=KEYS[2]; 
 local qtkey="sk:"..prodid..":qt";
 local usersKey="sk:"..prodid.":usr'; 
 local userExists=redis.call("sismember",usersKey,userid);
 if tonumber(userExists)==1 then 
   return 2; //2表示当前用户已经秒杀过了
 end
 local num= redis.call("get" ,qtkey);
 if tonumber(num)<=0 then 
   return 0;  //0表示秒杀已经结束了
 else 
   redis.call("decr",qtkey);
   redis.call("sadd",usersKey,userid);
 end
 return 1; //1表示成功

小结：

普通的redis代码可以实现秒杀功能但是都会存在问题

 问题1：连接超时和连接数量问题
 解决方法：通过redis数据库连接池来解决
 
 问题2：卖货在多并发下的超库问题
 解决办法：通过组队事务然后集体执行，（乐观锁实现）
 
 问题3：由于乐观锁本性，导致库存还有却卖货失败问题
 解决办法：用LUA脚本代码来实现局部的原子性，在redis事务执行阶段其他请求不会影响

12.Redis持久化RDB

什么是持久化？

Redis是存储在内存中的，将内存的数据存储到硬盘当中称之为持久化过程。

Redis提供了两种不同的持久化方式

RDB(Redis DataBase)
AOF(Append Of File)

本章先介绍RDB

12.1RDB

12.1.1官网介绍

12.1.2什么是RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

时间间隔，固定的时间点
数据集快照，当前时间点内存中的瞬间数据。

12.1.3RDB的过程

Redis在RDB备份过程中，会单独创建一个（fork）子进程来进行持久化的操作，会先将数据写入到一个临时文件中，持久化过程结束后，再用这个临时文件替换上一次持久化的文件。而这整个过程主线程不会进行IO操作，如果需要进行大规模数据的恢复且对数据恢复的完整性要求不高，RDB要由于AOF。但RDB的缺点是最后一次持久化会有数据丢失问题。

Fork（创建子进程的过程）：

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了写时复制技术

写时赋值技术：redis不会将所有的数据直接封存到rdb文件中，而是会通过fork产生一个临时区域和临时文件，当这个进程的任务完成后才将rdb的持久化文件替换，保证了数据的完整性和安全性。
式一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

12.1.4RDB的持久化文件，看redis.conf配置文件

1.在redis.conf中配置文件名称，默认为dump.rdb

2.rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下，dir "/myredis/"

3.stop-writes-on-bgsave-error

当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes.

4.rdbcompression 压缩文件

对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。

如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

5.rdbchecksum 检查完整性

在存储快照后，还可以让redis使用CRC64算法来进行数据校验，

但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能，推荐yes.

开启之后会在持久化之前检查数据是否完整是否有损坏，如果有损坏就终止持久化。

6.Save

格式：save 秒钟写操作次数，持久化操作之后时间和监视key改变的数量都会刷新重新开始。

RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，

默认是1分钟内改了10000次，或5分钟内改了10次，或15分钟内改了1次。就会触发持久化过程。

一般是禁用的，不设置save指令，或者给save传入空字符串

save 指令：save时只管保存，其它不管，全部阻塞。手动保存。不建议。

bgsave指令：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。

可以通过lastsave 命令获取最后一次成功执行快照的时间

 #在配置文件中设置在20s内只要有3个key发生改变就进行持久化
 save 20 3

12.2RDB的备份操作

在redis操作过程中数据出现了问题，希望可以恢复到之前的状态，就要用到rdb的备份。

 cp dump.rdb dumpCp.rdb      #赋值当前rdb文件到dumCp.rdb文件
 ps -ef | grep redis #查看redis进程
 kill - 9 3524 #杀掉redis进程
 rm -f dump.rdb #删除之前的rdb文件
 
 #恢复dump.rdb过程
 cp dumpCp.rdb dump.rdb / mv dump.rdb dumpCp.rdb
 redis-server /etc/redis.conf #启动redis服务
 redis-cli #后面就查看redis中的内容

12.3RDB的优缺点

优势：

适合大规模的数据恢复和保存
对数据完整性和一致性要求不高时使用
节省磁盘空间
恢复速度快

缺点：

fork的操作过程中，内存中的数据被克隆，会导致内存膨胀
虽然Redis在fork过程用到了写时拷贝技术，但是如果数据量过大还是比较消耗性能。
RDB在最后一次数据持久化的时候可能会造成数据的丢失解释为什么最后一次丢失，例如现在的要求是在20s内有10个key发生改变那么就进行持久化操作，但是还未达到持久化条件的过程中改变了key，同时服务器宕机就会导致数据丢失。

12.4如何停止RDB操作

动态停止

 redis-cli config set save "" #save后给空值，表示禁用保存策略

13.Redis的AOF持久化操作

13.1AOF概念

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

13.2AOF操作

AOF默认是不开启的，所以需要去配置文件中设置一下，默认为appendonly.aof

将appendonly no 改为 yes AOF文件的保存路径，同RDB的路径一致。

问题：如果AOF和RDB同时开启，redis到底服从哪个？

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

13.2.1AOF启动/修复/恢复功能

AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载

正常恢复：

修改默认的appendonly no，改为yes

将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)

恢复：重启redis然后重新加载

异常恢复：在aof文件追加过程中aof文件出现了损坏，redis可以对其进行恢复

修改默认的appendonly no，改为yes

如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复

返回的结果是之前和现在有哪些不同

的备份被写坏的AOF文件

恢复：重启redis，然后重新加载

13.3AOF配置介绍

13.3.1同步频率设置

在配置文件中设置

 appendfsync always
 #始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好，效率低完整性更好
 appendfsync everysec
 #每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
 appendfsync no
 #redis不主动进行同步，把同步时机交给操作系统

13.3.2Rewrite压缩

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

Rewrite的重写原理

AOF文件持续增长而过大时，会fork出一条新进程来将文件进行重写（也是先临时文件最后再rename），redis4.0之后是指把rdb的快照以2进制的形式附着在aof头部，作为已有的历史数据，替换掉原来的流水操作。

重写流程和之前的RDB是类似的，通过fork生成子进程将数据写入到aof临时文件，之后用新的aof文件替换之前的文件。

13.3.3AOF持久化流程

客户端在请求写命令时候会被append追加到AOF缓冲区中
AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF中
AOF文件大小超过重写策略或手动重写时，会对AOF文件进行rewrite重写，以压缩AOF的文件容量。
当redis服务重启的时候，会重新load加载AOF文件中的写操作达到恢复的目的。

13.4AOF优缺点

优点：

备份机制更加稳健，丢失数据概率更低
生成的文件是可读性较强的日志文件，通过操作AOF，处理错误操作

缺点：

比起RDB占用更多的空间，因为他它记录了不仅仅是数据还有操作
由于记录的东西比较多，恢复备份速度更慢
每次读写同步的话，性能较差。
存在个别bug导致恢复有问题

13.5AOF和RDB的选用条件

RDB是在指定时间内的快照存储，AOF是对你的操作进行日志追加

官方推荐两个都用

如果对数据的安全和完整性不敏感，选用RDB
同时不建议单独使用AOF，可能会出现BUG
如果只是做纯内存存储加快读写速度，可以两者都不用。

14、Redis的主从复制

14.1主从复制的概念

主机数据更新后根据配置和策略，自动同步到备机的master/slaver的机制，Master以写为主，Slaver以读为主。

因为数据库主要的目的是读写，而读取数据更是更多的情况，所以考虑将应用对数据的写直接修改到主库，而将主库的数据进行复制生成多个分库，让应用读取时候可以从多个库进行读取，减少数据库的压力

14.2主从复制的作用

可以实现读写分离：如果读写放在一个服务器会导致该服务器压力过大
数据容灾时的快速恢复：当一台服务器宕机，快速的切换从服务器
必须为一主多从的效果，但是如果主服务器挂掉怎么办？

考虑使用集群的方法，集群将多个主从机制进行关联达到服务的保证。

14.3主从复制的过程

拷贝多个redis.conf文件include(写绝对路径)

开启daemonize yes

Pid文件名字pidfile

指定端口port

Log文件名字

dump.rdb名字dbfilename

Appendonly 关掉或者换名字

1.创建/myredis文件夹

 mkdir /myredis
 cd /myredis
 /usr/local/bin/redis-server /etc/redis.conf

2.复制配置文件

 cp /etc/redis.conf /myredis/redis.conf  #复制redis中的配置文件到myredis文件夹

3.配置一主两从的效果，创建三个配置文件

*redis6379.conf

*redis6380.conf

*redis6381.conf

4.在三个配置文件中写入内容

 vi redis.conf
 vi redis6379.conf

打开redis6379.conf文件进行内容引入和配置

 include /myredis/redis.conf
 pidfile /var/run/redis_6379.pid
 port 6379
 dbfilename dump6379.rdb

复制一份6379的文件作为6380

 cp redis6379.conf redis6380.conf
 vi redis6380.conf
 
 include /myredis/redis.conf
 pidfile /var/run/redis_6380.pid
 port 6380
 dbfilename dump6380.rdb

同理复制一份6380到6381

5.根据三个配置文件启动三个redis服务

 redis-server redis6379.conf
 redis-server redis6380.conf
 redis-server redis6381.conf
 ps -ef | grep redis

6.查看三台主机运行的情况

 info replication #打印主从复制的相关信息

默认没启动就都是没有主机没有从机

7.配置从库

在6380和6381的服务器上执行

 slaveof 127.0.0.1 6379

之后在主机上新建和更改的数据，在从机上都可以读取到了。

如果主机挂掉，重启主机，一切都会恢复正常

从机重启需要再次设置主机目标

14.4主从复制的特点

14.4.1一主二仆

切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的k1,k2,k3是否也可以复制？

从机是否可以进行写操作？set可否？

主机shutdown后情况如何，从机是上位成为主机还是原地待命？

主机在宕机重新启动后，主机新增记录，是否会同步到从机？

其中一台从机宕机后情况如何，恢复时是否可以跟上主库。

 当从服务器重启后，从服务器并不会是之前的从服务器，而是需要通过指令再变为之前主机的从机才行。
 再变为从机后，所有的数据将会和主机进行从头的同步
 
 主服务器挂掉后，但是从服务器的角色仍然是从机，重启主机后，主机仍然是主机

14.4.2薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。从服务器的身份既是从机也是下一层的主机。

14.4.3反从为主

当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。

 slaveof no one  #将当前从机变为主机
 info replication #查看当前主机从机关系

14.5主从复制的原理

Slave启动成功连接到master后会发送一个sync（同步）命令
主服务器接到服务器发送来的同步消息后，会把主服务器数据先进性持久化，放入rdb文件，将rdb发送给从服务器，从服务器拿到rdb进行读取。

14.6哨兵模式

14.6.1什么是哨兵模式？

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

14.6.2使用的步骤

1.调整为一主二仆模式，6379带着6380，6381

2.在myredis目录下创建sentinel.conf文件，文件名字必须是这个，绝不能错

 mkdir sentinel.conf

3.配置文件进行填写

 sentinel monitor mymaster 127.0.0.1 6379 1 #为哨兵设置主机地址
 #其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。

4.启动哨兵

 redis-sentinel -> redis-server
 redis-server
 redis-sentinel /myredis/sentinel.conf #启动哨兵

5.当主机挂掉，从机将会被选举出一台作为主机

(大概10秒左右可以看到哨兵窗口日志，切换了新的主机)

哪个从机会被选举为主机呢？根据优先级别：slave-priority

原主机重启后会变为从机。

同时也是可以从日志中看到替换的过程的

7.复制延时

由于所有操作都是现在主机上进行操作，然后再同步更新到从机的，所以master同步到slave机器是一定会有延时的，当系统繁忙或者slave过多时，这个问题会加重。

14.6.3故障恢复方法

优先级在redis.conf中默认：slave-priority 100，值越小优先级越高

在新版本的redis中属性名为 replica-priority 100

偏移量优先是指从机中和主机的重复度最高的，即数据和主机最为接近的服务器。

每个redis实例启动后都会随机生成一个40位的runid。

14.6.4Java代码实现主从复制功能

 private static JedisSentinelPool jedisSentinelPool=null;
 
 public static  Jedis getJedisFromSentinel(){
     if(jedisSentinelPool==null){
             Set<String> sentinelSet=new HashSet<>();
             sentinelSet.add("192.168.11.103:26379");
 
             JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();
             jedisPoolConfig.setMaxTotal(10); //最大可用连接数
            jedisPoolConfig.setMaxIdle(5); //最大闲置连接数
            jedisPoolConfig.setMinIdle(5); //最小闲置连接数
            jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待
            jedisPoolConfig.setMaxWaitMillis(2000); //等待时间
            jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pong
 
            jedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
            return jedisSentinelPool.getResource();
                    }else{
            return jedisSentinelPool.getResource();
                    }
         }
 }

15.Redis的集群操作

问题背景：

当redis容量不够时，如何进行扩容？

并发写操作，redis如何分摊？

另外，主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。

之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置。

代理主机：客户端的请求先发送到代理主机然后进行任务的分配。

无中心化集群配置：客户的请求可以进行任何一台服务器的入口，服务器之间可以相互进行访问。

15.1什么是集群？

Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）：即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。

15.2集群模拟案例

1.首先要将之前的rdb和aof文件全都删除，防止对后续有干扰

 rm -rf dump63*  #表示以dump63开头的文件都删掉

2.制作6个redis服务端口：6379,80,81,89,90,91；其中呢79是主，89是从机，以此类推，79,80，81都是主机后面都是对应的从机

3.在对应的.conf文件下配置基本信息

内容如下

 include /myredis/redis.conf
 开启daemonize yes
 Pid文件名字
 指定端口
 Log文件名字
 Dump.rdb名字
 Appendonly 关掉或者换名字
 ###除此之外还需要添加这些个配置
 cluster-enabled yes    #打开集群模式
 cluster-config-file nodes-6379.conf  #设定节点配置文件名
 cluster-node-timeout 15000   #设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。

接下来将6379的conf文件进行复制五份

 cp redis6379.conf redis6380.conf
 cp redis6379.conf redis6381.conf
 cp redis6379.conf redis6382.conf
 cp redis6379.conf redis6389.conf
 cp redis6379.conf redis6390.conf
 cp redis6379.conf redis6391.conf

将这些内容都进行一下指定的修改

 :%s/6379/6380  #进行快速地统一替换

4.启动这6个redis服务

 ps -ef | grep redis #查看当前已经启动的redis服务
 
 redis-server redis6379.conf
 redis-server redis6380.conf
 redis-server redis6381.conf
 redis-server redis6389.conf
 redis-server redis6390.conf
 redis-server redis6391.conf

5.将这6个结点合成为1个集群

组合之前，请确保所有redis实例启动后，nodes-xxxx.conf文件都生成正常。

合体命令

 cd /opt/redis-6.2.1/src
 #到src目录下去进行集群操作
 redis-cli --cluster create --cluster-replicas 1 192.168.11.101:6379 192.168.11.101:6380 192.168.11.101:6381 192.168.11.101:6389 192.168.11.101:6390 192.168.11.101:6391

之后会返回一个值，这个我们先记下

普通方式登录

可能直接进入读主存，存储数据时候会出现MOVED重定向操作，所以应该以集群的方式登录。

因此考虑使用集群策略连接，设置连接数据会自动切换到

 redis-cli -c -p 6379 #就可以用集群的方式进行连接，用任何的端口都是可以的
 cluster nodes 查看集群中的所有结点信息

6.Redis cluster如何分配这6个结点？

分配的原则，尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在同一个IP地址上

15.3Slots

在搭建成功后会返回一个slots值

slots的意思是插槽

一个 Redis 集群包含 16384 个插槽（hash slot），数据库中的每个键都属于这 16384 个插槽的其中一个。

集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽，其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和。

集群中的每个节点负责处理一部分插槽。举个例子，如果一个集群可以有主节点，其中：

节点 A 负责处理 0 号至 5460 号插槽。

节点 B 负责处理 5461 号至 10922 号插槽。

节点 C 负责处理 10923 号至 16383 号插槽。

插槽的目的就是把数据尽可能三列的分布在集群的每一个服务器上

15.4在集群中录入键值

在redis-cli每次录入、查询键值，redis都会计算出该key应该送往的插槽，如果不是该客户端对应服务器的插槽，redis会报错，并告知应前往的redis实例地址和端口。

redis-cli客户端提供了 –c 参数实现自动重定向。

如 redis-cli -c –p 6379 登入后，再录入、查询键值对可以自动重定向。

不在一个slot下的键值，是不能使用mget,mset等多键操作。

可以通过{}来定义组的概念，从而使key中{}内相同内容的键值对放到一个slot中去。

15.5查询集群中的值

 cluster keyslot <key> #查找key值的插槽值（索引下标）
 
 cluster countkeysinslot 10000 #查找10000插槽值之内的有多少个key值，并且只可以看到自己服务器范围的值，别的服务库范围 的插槽值是查询不到的
 
 CLUSTER GETKEYSINSLOT <slot><count>  #返回 count 个 slot 槽中的键。

15.6故障恢复

例如现在一台服务器宕机了

首先看一下目前的服务器结点状况

 cluster nodes

可以看到当前的6379显示为fail，但是79之前的从机将会作为新的主机来提供服务

此时如果6379恢复之后，将会成为当前主机的从机

如果主机和从机都挂掉了，那么整个集群还是否会继续提供服务呢？不一定，看配置了

15.6Jedis集群操作

主要的接口：

JedisCluster(HostAndPort);

 public class JedisClusterTest {
   public static void main(String[] args) { 
      Set<HostAndPort>set =new HashSet<HostAndPort>();
      set.add(new HostAndPort("192.168.31.211",6379)); //由于redis集群是无中心化的，所以放入任何一个都是可以的
      JedisCluster jedisCluster=new JedisCluster(set);
      jedisCluster.set("k1", "v1");
      System.out.println(jedisCluster.get("k1"));
   }
 }

16.Redis应用问题的解决

16.1问题一：缓存穿透

问题描述：

 Key对应的数据源并不存在，所以每一次针对key的请求从缓存中都获取不到，请求可能会压垮数据源，请求会先查缓存，缓存有数据则返回，没有则去数据库中查。
 redis的命中率降低了，一直查询数据库而不查redis，导致数据库的压力过大，造成数据库崩溃

缓存穿透的原因

redis查不到数据
在操作中出现了很多的不正常的url访问

黑客的目的并不是得到你的数据而是让你的服务器瘫痪。

解决方案：

1.对空值进行缓存：当一个查询结果为空时，将这个k-v（null）存储到缓存中，设置很短的过期时间，定时让空缓存删除。

2.设置可访问的名单（白名单）：使用bitmaps（位操作，通过偏移量进行判断）类型定义一个可访问的名单，名单的id作为bitmaps的偏移量，每次访问和bitmaps里的id进行校对，如果不存在则拦截。

3.采用布隆过滤器：底层也是bitmaps。

4.进行实时监控：当发现Redis的命中率开始降低时，需要排查访问对象和访问的数据，设置黑名单。

16.2问题二：缓存击穿

问题描述：key对应的数据存在，但是在redis中过期，此时如果有大量的并发请求申请，这些请求会大并发的压向数据库，导致后端数据库崩溃。

现象：

①数据库的访问压力瞬时间增大了

②redis里面并没有出现大量的key过期

③redis正常运行但是数据库崩溃

原因

①redis中某个key过期了，恰巧有大量的访问这个key

解决方案：

1.预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入redis并加长有效时间
2.实时调整：现场监控热门数据，实时调整key的有效时间
3.使用锁：①在缓存失效的时候先等待而不是立即去load db ②先试用缓存工具中某些带成功的返回结果

16.3问题三：缓存雪崩

缓存雪崩与缓存击穿的区别在于这里针对很多key缓存，前者则是某一个key

正常访问：

缓存失效瞬间：

雪崩原因：

在极少的时间段内，查询大量的key集中过期情况，访问key时都跑去了db。

解决方案:

1.构建多级缓存架构： nginx缓存 + redis缓存 +其他缓存（ehcache）
2.使用锁或者队列（对数据库访问的时候尽量单线程，不被打扰，效率低）：用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况
3.设置过期标志更新缓存（尽量让key不要过期而是更新）：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。
4.将缓存失效时间分撒开（避免大量的key集体过期）：比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

16.4问题四：分布式锁

随着业务发展的需要，原本单体服务器部署的系统被演化为了分布集群系统，由于分布式系统多线程、多进程而且还都分布在不同的机器上，这将使原单击部署情况下的并发控制锁策略失效，单纯的JavaAPI并不提供分布式锁的能力，为了解决这类问题就需要跨JVM的互斥机制来控制共享资源的访问。

分布式锁主流实现方案：

基于数据库实现的分布式锁
基于缓存（Redis)
基于Zookeeper

各个分布式锁的优势：

性能：redis最高

可靠性：zookeeper最高

这里，我们就基于redis实现分布式锁。

16.4.1Redis实现分布式锁

命令

 #1.手动上锁删锁
 setnx users 10  #为user 这个key加了锁，没有释放都无法对其进行修改
 del users  #删除这个key即会释放锁
 
 #2.设置过期时间自动删除key
 setnx users 10
 expire users 10  #设置过期时间，自动删除锁和key资源
 
 #3.如果上锁后发生异常，无法设置时间
 #在上锁的过程中设置一下过期时间
 set users 10 nx ex 12    #表示users的value值为10,nx为上锁，ex后的数值为过期时间单位为s

 set sku:1:info "OK" NX PX10000

16.4.2Jedis实现上锁删锁等过程

 @GetMapping("testLock")
 public void testLock(){
     //获取锁
      Boolean lockSucceed = redisTemplate.opsForValue().setIfAbsent("keyOfLock", "111");
     //setIfAbsent 类似于 setnx
     //获取如果成功查询num的值
     if(lockSucced){
         Object value = redisTemplate.opsForValue().get("num");
         if(StringUtils.isEmpty(value)){
             return;
         }
         int num = Integer.parseInt(value+"");
         redisTemplate.opsForValue().set("num", ++num);
         //释放锁
         redisTemplate.delete("lock");
         
     }else{
         //3获取锁失败、每隔0.1秒再获取
         try {
             Thread.sleep(100);
             testLock();
         } catch (InterruptedException e) {
             e.printStackTrace();
         }
     }    
 }

压力测试通过ab测试基本没问题：

ab -n 1000 -c 100 http://192.168.140.1:8080/test/testLock

问题：setnx刚好获取到锁，业务逻辑出现异常，导致锁无法释放

解决：设置过期时间，自动释放锁。

 Boolean lockSucceed = redisTemplate.opsForValue().setIfAbsent("keyOfLock", "111",3,TimeUnit.SECONDS);
 //四个参数的方法表示获取到锁并且设置过期时间

16.4.3分布式锁的其他隐藏问题

1.释放了别人锁

操作A在执行过程中先对自己的资源上了锁，但是过程中出现了卡顿，导致过一会锁自动释放了但是A的操作还未执行完毕，这是操作B抢到了锁进行操作，A又反应了过来进行了操作并手动释放了锁，这就导致A释放了B的锁。

解决方案①：优化值UUID防止误删：只可以删自己的，不可以删别人的

第一步：用UUID表示不同的操作

 set lock UUDI nx ex 10

第二步：在释放锁的时候判断当前的UUID与要释放锁的UUID是否一致

 String uuid = UUID.randomUUID().toString();
 Boolean lockSucceed = redisTemplate.opsForValue().setIfAbsent("keyOfLock", UUID,3,TimeUnit.SECONDS);
 ....
 if(uuid.equals((String)redisTemplate.opsForValue().get("lock"))){ //判断当前环境中的锁和最初的锁uuid是否一直
     this.redisTemplate.delete("lock");
 }

解决方法②：用LUA脚本对Redis操作强行原子化

 @GetMapping("testLockLua")
 public void testLockLua() {
     //1 声明一个uuid ,将做为一个value 放入我们的key所对应的值中
     String uuid = UUID.randomUUID().toString();
     //2 定义一个锁：lua 脚本可以使用同一把锁，来实现删除！
     String skuId = "25"; // 访问skuId 为25号的商品 100008348542
     String locKey = "lock:" + skuId; // 锁住的是每个商品的数据
 
     // 3 获取锁
     Boolean lock = redisTemplate.opsForValue().setIfAbsent(locKey, uuid, 3, TimeUnit.SECONDS);
 
     // 第一种： lock 与过期时间中间不写任何的代码。
     // redisTemplate.expire("lock",10, TimeUnit.SECONDS);//设置过期时间
     // 如果true
     if (lock) {
         // 执行的业务逻辑开始
         // 获取缓存中的num 数据
         Object value = redisTemplate.opsForValue().get("num");
         // 如果是空直接返回
         if (StringUtils.isEmpty(value)) {
             return;
         }
         // 不是空 如果说在这出现了异常！ 那么delete 就删除失败！ 也就是说锁永远存在！
         int num = Integer.parseInt(value + "");
         // 使num 每次+1 放入缓存
         redisTemplate.opsForValue().set("num", String.valueOf(++num));
         /*使用lua脚本来锁*/
         // 定义lua 脚本
         String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
         // 使用redis执行lua执行
         DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
         redisScript.setScriptText(script);
         // 设置一下返回值类型 为Long
         // 因为删除判断的时候，返回的0,给其封装为数据类型。如果不封装那么默认返回String 类型，
         // 那么返回字符串与0 会有发生错误。
         redisScript.setResultType(Long.class);
         // 第一个要是script 脚本 ，第二个需要判断的key，第三个就是key所对应的值。
         redisTemplate.execute(redisScript, Arrays.asList(locKey), uuid);
     } else {
         // 其他线程等待
         try {
             // 睡眠
             Thread.sleep(1000);
             // 睡醒了之后，调用方法。
             testLockLua();
         } catch (InterruptedException e) {
             e.printStackTrace();
         }
     }
 }

这篇关于Redi6笔记分享（从NoSQL基础到分布式锁的介绍）的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！