redis 主从操作，集群使用实现高可用

紧接上一篇文章资料源于尚硅谷视频课程

http://www.redis.io  ----官网介绍

Redis 提供了2个不同形式的持久化方式。

1. RDB（Redis DataBase）
2. AOF（Append Of File）

1.Redis持久化之RDB

• 是什么

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

• 备份是如何执行的

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

• Fork

1. Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
2. 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
3. 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

1.1 持久化流程

1.2 dump.rdb文件

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

这个文件一般在这个启动的目录下 

•  配置文件中默认的快照配置

 

• 命令save VS bgsave

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

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

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

• flushall命令

执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

###SNAPSHOTTING快照###

• Save

格式：save 秒钟 写操作次数

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

默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。

禁用

不设置save指令，或者给save传入空字符串

• stop-writes-on-bgsave-error

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

• rdbcompression 压缩文件

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

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

• rdbchecksum 检查完整性

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

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

推荐yes.

rdb的备份

先通过config get dir  查询rdb文件的目录

将*.rdb的文件拷贝到别的地方

rdb的恢复

1. 1. 1. 关闭Redis
      2. 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
      3. 启动Redis, 备份数据会直接加载

优势

1. 适合大规模的数据恢复
2. 对数据完整性和一致性要求不高更适合使用
3. 节省磁盘空间
4. 恢复速度快

劣势

1. Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
2. 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
3. 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

如何停止

动态停止RDB：redis-cli config set save ""#save后给空值，表示禁用保存策略

2.Redis持久化之AOF

• 是什么

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

• AOF持久化流程

（1）客户端的请求写命令会被append追加到AOF缓冲区内；

（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

AOF默认不开启

可以在redis.conf中配置文件名称，默认为 appendonly.aof

AOF文件的保存路径，同RDB的路径一致。

AOF和RDB同时开启，redis听谁的？

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

AOF启动/修复/恢复

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

• 正常恢复

1. 修改默认的appendonly no，改为yes
2. 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
3. 恢复：重启redis然后重新加载

• 异常恢复

1. 修改默认的appendonly no，改为yes
2. 如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复
3. 备份被写坏的AOF文件
4. 恢复：重启redis，然后重新加载

AOF同步频率设置

appendfsync always

始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

redis不主动进行同步，把同步时机交给操作系统。

Rewrite压缩 

1是什么：

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

2重写原理，如何实现重写

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

no-appendfsync-on-rewrite：

如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

如果 no-appendfsync-on-rewrite=no,  还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

触发机制，何时重写

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）

auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,

如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

3、重写流程

（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。

（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

（4）1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。

（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

优势

1. 备份机制更稳健，丢失数据概率更低。
2. 可读的日志文本，通过操作AOF稳健，可以处理误操作。

劣势

1. 比起RDB占用更多的磁盘空间。
2. 恢复备份速度要慢。
3. 每次读写都同步的话，有一定的性能压力。

存在个别Bug，造成恢复不能。

2.1总结(Which one)

用哪个好

官方推荐两个都启用。

如果对数据不敏感，可以选单独用RDB。

不建议单独用 AOF，因为可能会出现Bug。

如果只是做纯内存缓存，可以都不用。

官网建议

1. RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
2. AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
3. Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
4. 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
5. 同时开启两种持久化方式
6. 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
7. RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？
8. 建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
9. 性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。 如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。 代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。 只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。 默认超过原大小100%大小时重写可以改到适当的数值。

3.Redis_主从复制 

3.1概念

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

3.2作用

1. 读写分离，性能扩展
2. 容灾快速恢复

 3.3 搭建主从节点

我们按照准备另外2个虚拟机 然后启动redis数据库服务器

步骤和之前的一样可以看这个文章

redie安装

3.3.1 添加主从

配从(库)不配主(库)

slaveof  

成为某个实例的从服务器

在其他服务器上执行（你认定的从节点）

127.0.0.1:6379> slaveof 192.168.1.113 6379

查看节点状态

127.0.0.1:6379> info replication

 从节点信息

 主节点信息

配置好后自由主节点可以写数据，从节点只可以读。

注意点！！！！

1.主节点死机重启任然是主节点

2.从节点死机，重启后断开主从链接，成为自己的主节点。需要重新建立链接

3.但是数据不会丢失

4.主从节点的运作原理

1. Slave启动成功连接到master后会发送一个sync命令
2. Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
3. 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
4. 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
5. 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行

        因此启用主从模式一定要开启RDB持久化

3.3.2 主从的传递节点

 就是主节点1的从节点1，可以成为主节点2去链入下一个从节点

类似的意思是公司老板带经理，经理带员工

3.3.3 节点身份互换

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

用 slaveof  no one  将从机变为主机。

因为我们在上面介绍带，从节点死机后可以成为主节点。但是主节点死机后 他的从节点还是从节点。这样相当于一个公司的老板离开了就没有新的老板这样肯定是不可以的。

执行力上述的指令后节点就可以成为主节点。

3.4 哨兵模式

• 概念

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

配置概念图我们采用1主2从的构建模式

•  配置信息

在自己的工程目录下新建sentinel.conf文件，名字绝不能错

• 内容

sentinel monitor mymaster 127.0.0.1 6379 1

其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。

• 启动哨兵

redis可以用自带的redis-benchmark工具

执行redis-sentinel  sentinel.conf

启动成功哨兵模式的端口时候26379

当我们进行监听了之后，如果当前的主节点挂机了，被哨兵模式监听到了。哨兵模式会根据一定的优先级条件分配从节点当选主节点。

根据优先级别：slave-priority xx（启动服务的配置文件里面 xx是有限等级）

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

​​​​​​​3.5复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

4.多主机集群搭建

在前面实现机器的主从的时候我们创建了3台虚拟机，现在我们将3台虚拟机实现成集群。

4.1概念

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

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

4.2 配置准备

删除所有的持久化文件将rdb,aof文件都删除掉。（实现集群数据的统一）

在3台虚拟机的6379端口的配置文件配置如下

daemonize yes

cluster-enabled yes    打开集群模式

cluster-config-file nodes-6379.conf  设定节点配置文件名

cluster-node-timeout 15000   设定节点失联时间，超过该时间（毫秒），集群自动进行主从切换。

进入控制台清空数据库 flushdb

注意!!!

在构建集群的之前不要将需要构建数据库配置主从环境，要先构建集群之后再 构建主从环境

为了降低成本 后面的主从配置，我会在本机的6380端口配置为本机6379的从节点

进入解压下来的redis配置文件目录（根据你的来）

进入src

执行命令

redis-cli --cluster create 192.168.1.113:6379 192.168.1.114:6379 192.168.1.115:6379

集群模式进入 

查看集群节点信息

集群配置完成之后，我们在本机的服务下复制redis.conf的配置文件修改端口为6380作为本机6379的从节点。实现了下图的环境配置 

黄色的部分为一个redis集群，然后橙色的部分为对应主机下的集群机器的从节点。每当主节点挂接从节点会顶替而上。正常情况下，从节点也应该是另一个机器的服务环境。（简单的说主从节点也不应该在一台机器上） 

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

这样有一个机器挂机了就有顶替的服务器实现了高可用

每次重启服务器需要再次手动打开集群。

4.3 集群的插槽

 我们在配置成功了redis集群中他会返回一个集群信息，每个服务的后面的数值范围表示的就是该服务的插槽范围。

我是这样的理解的整个redis是一个数组，插槽就是下标。

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

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

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

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

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

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

每次执行成功后会返回插槽的数值并且自动切换对应的数据库服务地址。

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

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

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

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

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

 

查询集群中的值

 

CLUSTER GETKEYSINSLOT 返回有多少条记录

CLUSTER GETKEYSINSLOT 返回 count 个 slot 槽中的键。

这些指令查询的插槽对应你现在数据库服务

比如说a服务器 0-500那么只能查询0-500插槽的的结果。

4.3.1 java操作机集群

    @Test
    void Group(){
        HostAndPort hostAndPort = new HostAndPort("192.168.1.114", 6379);
        JedisCluster jedisCluster=new JedisCluster(hostAndPort);
        jedisCluster.set("ka","va");
        String kaValue = jedisCluster.get("ka");
        System.out.println("输出得到的:"+kaValue);
        jedisCluster.close();
    }

区别就是创建的对象不同其他操作基本相同

4.4 Redis 集群提供了以下好处

实现扩容

分摊压力

无中心配置相对简单

4.5 Redis 集群的不足

多键操作是不被支持的

多键的Redis事务是不被支持的。lua脚本不被支持

由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

 5.缓存穿透

5.1 描述场景

key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

说的简单一点就是每次对服务器进行访问的时候，服务器对数据库进行检索，但是是没有对应的数据的这个时候我们一般是不会将没有值的数据进行缓存这样，服务器访问数据库的压力就过大了。

5.2解决方案

一个一定不存在缓存及查询不到的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

解决方案：

对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟

设置可访问的名单（白名单）：

使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

采用布隆过滤器：(布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量(位图)和一系列随机映射函数（哈希函数）。

布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。)

将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被 这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。

进行实时监控：当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务

6.缓存击穿​​​​​​​

6.1 问题描述

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

 

6.2解决方案

key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题。

解决问题：

（1）预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长

（2）实时调整：现场监控哪些数据热门，实时调整key的过期时长

（3）使用锁：

1. 就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db。
2. 先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key
3. 当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；
4. 当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

 

7.缓存雪崩

7.1问题描述

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

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

• 正常情况

• 异常情况 

7.2解决方案

缓存失效时的雪崩效应对底层系统的冲击非常可怕！

解决方案：

构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）​​​​​​​

使用锁或队列：

用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况

设置过期标志更新缓存：

记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。

将缓存失效时间分散开：

比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

8.分布式锁

8.1问题描述

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

分布式锁主流的实现方案：

1. 基于数据库实现分布式锁

2. 基于缓存（Redis等）

3. 基于Zookeeper

每一种分布式锁解决方案都有各自的优缺点：

1. 性能：redis最高

2. 可靠性：zookeeper最高

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

8.2解决方案：使用redis实现分布式锁

setnx key value  给key设置锁值为value 如果存在这个key不进行操作（永久上锁）

del user 删除这个key 同时意味着解锁

expire key10 给key设置过去时间 10 过期时间到了可以重新设置

set key value nx ex 15 设置key的值value nx上锁 ex设置过期时间15s

127.0.0.1:6379> setnx user 10
(integer) 1
127.0.0.1:6379> setnx user 10
(integer) 0
127.0.0.1:6379> setnx user 20
(integer) 0
127.0.0.1:6379> del user
(integer) 1
127.0.0.1:6379> setnx user 20
(integer) 1
127.0.0.1:6379> setnx user 99
(integer) 0
127.0.0.1:6379> expire user 10
(integer) 1
127.0.0.1:6379> ttl user
(integer) 6
127.0.0.1:6379> setnx user 99
(integer) 1
127.0.0.1:6379> set k1 v1 nx ex 15
OK
127.0.0.1:6379> ttl k1
(integer) 12
127.0.0.1:6379> setnx k1 k2
(integer) 0
127.0.0.1:6379> ttl k1
(integer) 3
127.0.0.1:6379> setnx k1 k2
(integer) 1
127.0.0.1:6379> get k1
"k2"
127.0.0.1:6379>

 

1. 多个客户端同时获取锁（setnx）

2. 获取成功，执行业务逻辑{从db获取数据，放入缓存}，执行完成释放锁（del）

3. 其他客户端等待重试

 

8.2 代码演示

 @GetMapping("/locktest")
    public void testLock(){
        //1获取锁，setne
        Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111");
        //2获取锁成功、查询num的值
        if(lock){
            Object value = redisTemplate.opsForValue().get("num");
            //2.1判断num为空return
            if(StringUtils.isEmpty(value)){
                return;
            }
            //2.2有值就转成成int
            Integer num = Integer.parseInt(value+"");
            //2.3把redis的num加1
            redisTemplate.opsForValue().set("num", ++num);
            //2.4释放锁，del
            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.1.102:8080/api/redisTest/locktest

8.3 优化之加入uuid和过期时间

 @GetMapping("/locktest")
    public void testLock(){
        String uuid = UUID.randomUUID().toString();
        //1获取锁，setne 上锁  setnx ,return true=成功
        /**
         * 设置锁
         * 1.key
         * 2.value uuid唯一标识
         * 3.过期时间
         * 4.时间单位
         */
        Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock",uuid,3,TimeUnit.SECONDS);
        //2获取锁成功、查询num的值
        if(lock){
            Object value = redisTemplate.opsForValue().get("num");
            //2.1判断num为空return
            if(StringUtils.isEmpty(value)){
                return;
            }
            //2.2有值就转成成int
            Integer num = Integer.parseInt(value+"");
            //2.3把redis的num加1
            redisTemplate.opsForValue().set("num", ++num);
            //2.4释放锁，del 加入uuid识别防止误删或者错误操作
            if (uuid.equals(redisTemplate.opsForValue().get("lock"))){
                redisTemplate.delete("lock");
            }
      

        }else{
            //3获取锁失败、每隔0.1秒再获取
            try {
                Thread.sleep(100);
                testLock();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

 问题：删除操作缺乏原子性。也就是说我在执行第一个任务的线程的时候会被同时间的另一个任务线程干扰。

 

8.4优化之LUA脚本保证删除的原子性

 @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 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();
            }
        }
    }

为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：

- 互斥性。在任意时刻，只有一个客户端能持有锁。

- 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。

- 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。

- 加锁和解锁必须具有原子性。

​​​​​​​9.ACL

• 简介

Redis ACL是Access Control List（访问控制列表）的缩写，该功能允许根据可以执行的命令和可以访问的键来限制某些连接。

在Redis 5版本之前，Redis 安全规则只有密码控制 还有通过rename 来调整高危命令比如 flushdb ， KEYS* ， shutdown 等。Redis 6 则提供ACL的功能对用户进行更细粒度的权限控制 ：

（1）接入权限:用户名和密码

（2）可以执行的命令

（3）可以操作的 KEY

参考官网：https://redis.io/topics/acl

• 命令

1、使用acl list命令展现用户权限列表

（1）数据说明

2、 acl cat命令查看添加权限指令类别

 使用acl whoami命令查看当前用户

ACL规则

下面是有效ACL规则的列表。某些规则只是用于激活或删除标志，或对用户ACL执行给定更改的单个单词。其他规则是字符前缀，它们与命令或类别名称、键模式等连接在一起。

ACL规则
类型	参数	说明
启动和禁用用户	on	激活某用户账号
	off	禁用某用户账号。注意，已验证的连接仍然可以工作。如果默认用户被标记为off，则新连接将在未进行身份验证的情况下启动，并要求用户使用AUTH选项发送AUTH或HELLO，以便以某种方式进行身份验证。
权限的添加删除	+	将指令添加到用户可以调用的指令列表中
	-	从用户可执行指令列表移除指令
	+@	添加该类别中用户要调用的所有指令，有效类别为@admin、@set、@sortedset…等，通过调用ACL CAT命令查看完整列表。特殊类别@all表示所有命令，包括当前存在于服务器中的命令，以及将来将通过模块加载的命令。
	-@	从用户可调用指令中移除类别
	allcommands	+@all的别名
	nocommand	-@all的别名
可操作键的添加或删除	~	添加可作为用户可操作的键的模式。例如~*允许所有的键

（2）通过命令创建新用户默认权限

acl setuser user1

在上面的示例中，我根本没有指定任何规则。如果用户不存在，这将使用just created的默认属性来创建用户。如果用户已经存在，则上面的命令将不执行任何操作。

（3）设置有用户名、密码、ACL权限、并启用的用户

acl setuser user2 on >password ~cached:* +get

(4)切换用户，验证权限

 

10.IO多线程

简介

Redis6终于支撑多线程了，告别单线程了吗？

IO多线程其实指客户端交互部分的网络IO交互处理模块多线程，而非执行命令多线程。Redis6执行命令依然是单线程。

原理架构

Redis 6 加入多线程,但跟 Memcached 这种从 IO处理到数据访问多线程的实现模式有些差异。Redis 的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程。之所以这么设计是不想因为多线程而变得复杂，需要去控制 key、lua、事务，LPUSH/LPOP 等等的并发问题。整体的设计大体如下:

另外，多线程IO默认也是不开启的，需要再配置文件中配置

io-threads-do-reads  yes

io-threads 4