一.Redis事务和锁机制
1.事务的概念
Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
Redis事务的主要作用就是串联多个命令防止别的命令插队。
2.事务的命令
从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行。
组队的过程中可以通过discard来放弃组队。
exec
discard
3.事务的错误处理
1.组队阶段发生错误
可以观察到组队阶段发生错误,所有的组队阶段的指令都不会被执行
4.执行阶段发生错误
可以观察到执行阶段发生错误,只有有错误的指令不会被执行,其他的指令可以正常被执行,因此redis事务的操作不具备原子性(要么全成功,要么全失败),redis事务只是将一群指令一起执行.
4.悲观锁和乐观锁
三个人同时去操作一个账户,账户原本有10000元,此时三个人同时去买东西,当三个人同时去买东西扣费的时候,最终账户的钱会变成-4000元,这时就不符合生活常识了.
1.悲观锁
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
2.乐观锁
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。
5.Redis中的乐观锁
WATCH key [key ...]:
在执行multi之前，先执行watch key1 [key2],可以监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
客户端一:
客户端二:
可以看到客户端一对balance的值进行改动,客户端二如果再对balance值进行改动,就会返回nil,也就是执行失败的执行,此时就是乐观锁对事物操作进行了检验
注意:要在客户端一执行事务之前开启客户端二的事务操作,exec客户端一的命令之后,再exec客户端二的命令,这个时候客户端二才会执行失败
unwatch:取消 WATCH 命令对所有 key 的监视
6.Redis事务三特性
- 单独的隔离操作
事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。 - 没有隔离级别的概念
队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行 - 不保证原子性
事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚
7.秒杀案例
1.秒杀案例的redis键值设置
2.下载测试工具
yum install httpd-tools
-n为请求的数量 -c是并发的数量 -p是post请求提交的参数 -T是请求的类型
3.通过ab测试
vim postfile 模拟表单提交参数,以&符号结尾;存放当前目录。
prodid=0101&
ab -n 2000 -c 200 -k -p ~/postfile -T application/x-www-form-urlencoded http://192.168.2.115:8081/Seckill/doseckill
4.编写秒杀代码
public class deSecKill {
public static void main(String[] args) {
}
//秒杀过程
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);//3拼接key
//3.1库存key
String kcKey = "sk:" + prodid + ":qt";
// 3.2秒杀成功用户key
String userKey = "sk:" + prodid + ":user";
String kc = jedis.get(kcKey);
//4获取库存，如果库存null，秒杀还没有开始
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秒杀过程
// 7.1库存-1
jedis.decr(kcKey);
//7.2把秒杀成功用户添加清单里面jedis.sadd(userKey, uid) ;
System.out.println("秒杀成功了..");
jedis.close();
return true;
}
}
点击秒杀按钮一次,redis中的数据(此时相当于串行操作)
5.超卖问题
当我们使用并发工具进行操作时候,控制台输出如下:可以发现秒杀结束之后又成功了
可以使用乐观锁进行解决
使用事务解决超卖问题
6.连接超时问题
当我们一次处理多个请求的时候,多个请求同时请求redis,此时如果当一个请求的时间很长,其他的请求等待时间过长就会出现连接超时问题
连接超时，通过连接池解决
节省每次连接redis服务带来的消耗，把连接好的实例反复利用。
通过参数管理连接的行为
package com.javastudy;
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);
}
}
}
- 连接池参数
- MaxTotal：控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取；如果赋值为-1，则表示不限制；如果pool已经分配了MaxTotal个jedis实例，则此时pool的状态为exhausted。
- maxIdle：控制一个pool最多有多少个状态为idle(空闲)的jedis实例；
- MaxWaitMillis：表示当borrow一个jedis实例时，最大的等待毫秒数，如果超过等待时间，则直接抛JedisConnectionException；
将第二步连接redis的操作用连接池进行修改
7.库存遗留问题
已经秒光，可是还有库存。原因，就是乐观锁导致很多请求都失败。先点的没秒到，后点的可能秒到了。
8.LUA脚本解决库存遗留问题
Lua 是一个小巧的脚本语言，Lua脚本可以很容易的被C/C++ 代码调用，也可以反过来调用C/C++的函数，Lua并没有提供强大的库，一个完整的Lua解释器不过200k，所以Lua不适合作为开发独立应用程序的语言，而是作为嵌入式脚本语言。
很多应用程序、游戏使用LUA作为自己的嵌入式脚本语言，以此来实现可配置性、可扩展性。
LUA脚本在Redis中的优势
将复杂的或者多步的redis操作，写为一个脚本，一次提交给redis执行，减少反复连接redis的次数。提升性能。
LUA脚本是类似redis事务，有一定的原子性，不会被其他命令插队，可以完成一些redis事务性的操作。
但是注意redis的lua脚本功能，只有在Redis 2.6以上的版本才可以使用。
利用lua脚本淘汰用户，解决超卖问题。
redis 2.6版本以后，通过lua脚本解决争抢问题，实际上是redis 利用其单线程的特性，用任务队列的方式解决多任务并发问题。
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;
end
local num= redis.call("get" ,qtkey);
if tonumber(num)<=0 then
return 0;
else
redis.call("decr",qtkey);
redis.call("sadd",usersKey,userid);
end
return 1;修改后的代码
package com.javastudy.jedis;
import org.slf4j.LoggerFactory;
import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import java.io.IOException;
import java.util.HashSet;
import java.util.Set;
/**
* @author Chooker
* @create 2023-09-07 20:31
*/
public class SecKill_redisByScript {
private static final org.slf4j.Logger logger = LoggerFactory.getLogger(SecKill_redisByScript.class) ;
public static void main(String[] args) throws IOException {
JedisPool jedispool = JedisPoolUtil.getJedisPoolInstance();
Jedis jedis=jedispool.getResource();
System.out.println(jedis.ping());
Set<HostAndPort> set=new HashSet<>();
doSecKill("201", "sk:0101");
}
static String secKillScript ="local userid=KEYS[1];\r\n" +
"local prodid=KEYS[2];\r\n" +
"local qtkey='sk:'..prodid..\":qt\";\r\n" +
"local usersKey='sk:'..prodid..\":usr\";\r\n" +
"local userExists=redis.call(\"sismember\",usersKey,userid);\r\n" +
"if tonumber(userExists)==1 then \r\n" +
" return 2;\r\n" +
"end\r\n" +
"local num= redis.call(\"get\" ,qtkey);\r\n" +
"if tonumber(num)<=0 then \r\n" +
" return 0;\r\n" +
"else \r\n" +
" redis.call(\"decr\",qtkey);\r\n" +
" redis.call(\"sadd\",usersKey,userid);\r\n" +
"end\r\n" +
"return 1" ;
static String secKillScript2 =
"local userExists=redis.call(\"sismember\",\"{sk}:0101:usr\",userid);\r\n" +
" return 1";
public static boolean doSecKill(String uid,String prodid) throws IOException {
JedisPool jedispool = JedisPoolUtil.getJedisPoolInstance();
Jedis jedis=jedispool.getResource();
//String sha1= .secKillScript;
String sha1= jedis.scriptLoad(secKillScript);
Object result= jedis.evalsha(sha1, 2, uid,prodid);
String reString=String.valueOf(result);
if ("0".equals( reString ) ) {
System.err.println("已抢空！！");
}else if("1".equals( reString ) ) {
System.out.println("抢购成功！！！！");
}else if("2".equals( reString ) ) {
System.err.println("该用户已抢过！！");
}else{
System.err.println("抢购异常！！");
}
jedis.close();
return true;
}
}
二.Redis持久化操作
Redis 提供了2个不同形式的持久化方式。
- RDB（Redis DataBase）
- AOF（Append Of File）
1.RDB(redis database)
1.什么是RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
2.备份如何被执行
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
3.什么是fork
- Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
- 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
- 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。
4.RDB持久化流程
5.SNAPSHOTTING
1.stop-writes-on-bgsave-error
当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes.
2.rdbcompression
对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.
3.rdbchecksum
在存储快照后，还可以让redis使用CRC64算法来进行数据校验，
但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能,推荐yes.
4.默认名称
RDB的默认名称
5.配置位置
rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下
6.save
格式：save 秒钟 写操作次数
RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，
默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。
禁用
不设置save指令，或者给save传入空字符串
表示此时20s内至少有3个可以发生变化,就将数据放入到dump.rdb中
此时我们可以看到以下的变化 
save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。
bgsave：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
6.rdb的优缺点
优点
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高更适合使用
- 节省磁盘空间
- 恢复速度快
缺点
- Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
- 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
- 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。
2.AOF(append only file)
1.什么是AOF
以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
2.AOF持久化流程
（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；
3.AOF配置
AOF同步策略的设置
appendfsync always
始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync no
redis不主动进行同步，把同步时机交给操作系统。
此时我们重启redis使配置生效
开启之后默认生成了appendonly.aof文件
当我们进入redis的时候,可以发现我们之前的数据全部丢失了,这是为什么呢?
注意:AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）,因为之前aof文件是空的,所以重启的时候加载aof文件,redis中也没有数据.
4.AOF启动/修复/恢复
当我们重启之后,可以发现所有的数据全部恢复成功
总结:
AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
正常恢复
- 修改默认的appendonly no，改为yes
- 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
- 恢复：重启redis然后重新加载
异常恢复
- 修改默认的appendonly no，改为yes
- 如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复
- 备份被写坏的AOF文件
- 恢复：重启redis，然后重新加载
查看aof文件,可以看到里面保存的都是操作时修改数据的指令
当aof文件损坏的时候(在这里模拟损坏,加个hello语句)
此时我们重启redis服务,会报以下的错误,并且redis进程也并没有启动成功
此时我们对aof文件进行修复
查看aof文件,此时可以看到我们添加的内容已经被修复
5.Rewrite压缩
1.什么是rewrite
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
2.重写原理
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。
3.触发机制
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
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进行重写。
4.重写流程
- bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
- 主进程fork出子进程执行重写操作，保证主进程不会阻塞。
- 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
- 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
- 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。
6.AOF优缺点
优点
- 备份机制更稳健，丢失数据概率更低。
- 可读的日志文本，通过操作AOF稳健，可以处理误操作。
缺点
- 比起RDB占用更多的磁盘空间。
- 恢复备份速度要慢。
- 每次读写都同步的话，有一定的性能压力。
- 存在个别Bug，造成恢复不能。
3.AOF和RDB总结
官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。
- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
- Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
- 只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
- 同时开启两种持久化方式.在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
代价:
一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
三.Redis主从操作
1.什么是主从复制
主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主
主从模式的好处:
- 读写分离，性能扩展
-
容灾快速恢复
2.搭建一主多从
1.创建myredis目录
2.复制redis.conf文件到当前目录
3.配置一主两从，创建三个配置文件
关闭aof
创建redis6379.conf
include /root/myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
新建redis6380.conf，填写以下内容
可以直接将redis6379.conf进行复制 cp redis6379.conf redis6380.conf
vi命令中%s/79/80进行修改
新建redis6381.conf 同理上一个
4.启动服务
需要先把之前的redis服务停掉
5.查看三台主机的运行情况
使用info replication
可以观察到打印的信息都是主机
6.配从(库)不配主(库)
slaveof <ip><port> 成为某个实例的从服务器
打印信息可以看到6380和6381 都变成了slave
在6379中可以观察到
在6379中进行写操作,可以看到在6380和6381中也可以看到写入的数据,但是在6380和6381中无法进行写操作,只能进行读操作
3.复制原理
- Slave启动成功连接到master后会发送一个sync命令
- Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
- 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
- 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步.但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
4.一主二仆
当从服务器挂掉之后,再重启从服务器,从服务器此时变成了主服务器,重新输入与slaveof指令可以让重启的服务器再次变为从服务器
在从服务器挂掉的时候,主服务器添加数据,这个时候从服务器重启并且使用slaveof主服务器的时候,主服务器的数据还是会全部复制到从服务器上
当主服务器挂掉的时候,从服务器还是从服务器,只不过从服务器上可以看到主服务器已经挂掉
5.薪火相传
上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。
风险是一旦某个slave宕机，后面的slave都没法备份
主机挂了，从机还是从机，无法写数据了
6.反客为主
当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。
用 slaveof no one 将从机变为主机。
但是这个操作需要手动进行
7.哨兵模式(sentinel)
1.什么是哨兵模式
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
2.配置哨兵模式
自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错
配置哨兵,填写内容
sentinel monitor mymaster 127.0.0.1 6379 1
其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。
启动哨兵
当主机挂掉，从机选举中产生新的主机
3.故障恢复
优先级在redis.conf中默认：replica-priority 100，值越小优先级越高
偏移量是指获得原主机数据最完整的
每个redis实例启动后都会随机生成一个40位的runid
4.代码实现
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();
}
}四.集群
1.问题
主从模式，薪火相传模式，主机宕机，导致ip地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。
之前通过代理主机来解决，但是redis3.0中提供了解决方案。就是无中心化集群配置。
下面是代理主机,客户端通过请求代理服务器,通过代理服务器将请求分发到指定的服务器进行处理
这种有一定的缺点,就是服务器使用的过多,维护成本高.
无中心化集群中任何一台服务器都可以作为服务的入口,通过任何一台服务器,可以将服务转发到指定的服务器进行处理
2.什么是集群
Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。
3.搭建Redis集群
1.删除持久化文件
将rdb,aof文件都删除掉。
2.制作6个实例，6379,6380,6381,6389,6390,6391
3.配置基本信息
include /root/myredis/redis.conf
pidfile "/var/run/redis_6379.pid"port 6379
dbfilename "dump6379.rdb"cluster-enabled yes
cluster-config-file nodes-6379.confcluster-node-timeout 15000
修改器其他配置文件的信息,修改6379变为其他的端口,比如%s/6379/6380
4.启动6个redis服务
5.将六个节点合成一个集群
进入到安装目录
cd /opt/redis-6.2.1/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
此处不要用127.0.0.1， 请用真实IP地址
--replicas 1 采用最简单的方式配置集群，一台主机，一台从机，正好三组。
4.集群的分配原则
一个集群至少要有三个主节点。
选项 --cluster-replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。
分配原则尽量保证每个主数据库运行在不同的IP地址，每个从库和主库不在一个IP地址上。
5.什么是slots
一个 Redis 集群包含 16384 个插槽（hash slot）， 数据库中的每个键都属于这 16384 个插槽的其中一个，
集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
集群中的每个节点负责处理一部分插槽。 举个例子， 如果一个集群可以有主节点， 其中：
节点 A 负责处理 0 号至 5460 号插槽。
节点 B 负责处理 5461 号至 10922 号插槽。
节点 C 负责处理 10923 号至 16383 号插槽。
6.在集群中录入值
可以看到k1保存到了6381服务器上,k2保存到了6379服务器上.
插入多个值的时候,使用的组的方式进行插入,此时name,age都是属于user组的,根据user组
7.查询集群中的值
cluster keyslot [key]:查看key的卡槽值
cluster coutkeysinslot [slot value]:查看卡槽值中有多少个值,只能查看自己卡槽中的
cluster getkeysinslot: 返回 count 个 slot 槽中的键
8.故障恢复
如果主机挂掉,从机上位变为主机,当之前的主机回复之后,会变为从机
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为yes ，那么 ，整个集群都挂掉
如果某一段插槽的主从都挂掉，而cluster-require-full-coverage 为no ，那么，该插槽数据全都不能使用，也无法存储。
9.集群的Jedis开发
public class JedisClusterTest {
public static void main(String[] args) {
Set<HostAndPort>set =new HashSet<HostAndPort>();
set.add(new HostAndPort("192.168.31.211",6379));
JedisCluster jedisCluster=new JedisCluster(set);
jedisCluster.set("k1", "v1");
System.out.println(jedisCluster.get("k1"));
}
}10.集群的好处和不足
Redis 集群提供了以下好处
- 实现扩容
- 分摊压力
- 无中心配置相对简单
Redis 集群的不足
- 多键操作是不被支持的
- 多键的Redis事务是不被支持的。lua脚本不被支持
- 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大
五.应用问题解决
1.缓存雪崩
缓存雪崩是指在缓存中大量的键同时过期或失效，导致请求直接访问数据库或后端服务，给数据库或后端服务造成巨大压力，导致系统性能下降甚至崩溃的现象。
缓存雪崩可能发生的原因包括：
- 大量缓存键同时过期：当缓存键设置了相同的过期时间，或者由于某种原因导致大量的键同时失效，会导致缓存雪崩。
- 缓存服务器故障：当缓存服务器发生故障，无法提供服务时，请求将直接访问后端服务，导致压力集中在后端服务上。
为了解决缓存雪崩问题，可以采取以下策略：
- 设置随机过期时间：为缓存键设置随机的过期时间，避免大量键同时过期的情况发生，减少缓存雪崩的概率。
- 实现缓存预热：在系统启动或缓存失效前，提前加载热门数据到缓存中，避免在关键时刻大量请求直接访问后端服务。
- 使用分布式缓存：将缓存数据分布在多个缓存节点上，通过分散请求负载来减少单个缓存节点的压力，提高系统的可用性和抗压能力。
- 设置熔断机制：在缓存失效的情况下，通过设置熔断机制，直接返回默认值或错误信息，避免请求直接访问后端服务，减轻后端服务的压力。
- 实时监控和报警：监控缓存系统的状态和性能指标，及时发现异常情况，并通过报警机制通知运维人员进行处理，减少缓存雪崩的影响。
2.缓存穿透
缓存穿透是指在缓存系统中，大量的请求查询不存在于缓存和数据库中的数据，导致这些请求直接访问数据库，占用数据库资源，而缓存无法发挥作用的现象。
缓存穿透可能发生的原因包括：
- 恶意请求（异常情况）：攻击者发送大量恶意请求，故意查询不存在的数据，以触发缓存穿透。
- 高并发请求（正常业务）：当有大量的并发请求同时查询不存在的数据时，可能会导致缓存无法命中，从而触发缓存穿透。
为了解决缓存穿透问题，可以采取以下策略：
- 布隆过滤器（Bloom Filter）：布隆过滤器是一种高效的数据结构，可以用于快速判断一个元素是否存在于集合中。在缓存层引入布隆过滤器，可以在查询请求到达时，首先通过布隆过滤器判断该请求对应的数据是否存在于缓存或数据库中，从而避免无效的查询操作。
- 缓存空值处理：对于查询数据库返回的空结果，也可以将空结果缓存起来，设置一个较短的过期时间，避免频繁查询数据库。这样在下次查询相同的数据时，可以直接从缓存中获取空结果，而不需要再次查询数据库。
- 异步加载缓存：当缓存未命中时，可以异步加载数据到缓存中，避免在高并发场景下直接访问数据库。在异步加载过程中，可以通过互斥锁或分布式锁来保证只有一个线程去加载数据，避免重复加载。
- 设置热点数据永不过期：对于一些热点数据，可以将其设置为永不过期，或者过期时间较长，以保证这部分数据始终在缓存中可用。
- 限制恶意请求：通过访问频率控制、验证码等手段，限制对缓存的恶意请求，防止攻击者通过查询不存在的数据来触发缓存穿透。
3.缓存击穿
缓存击穿是指在缓存系统中，某个热点数据过期或失效时，同时有大量的请求访问该数据，导致请求直接访问数据库或后端服务，给数据库或后端服务造成巨大压力，导致系统性能下降甚至崩溃的现象。
缓存击穿可能发生的原因包括：
- 热点数据失效：当某个热点数据过期时，此时大量请求访问该数据，导致缓存失效，请求直接访问数据库。
- 并发访问热点数据：在高并发环境下，大量的请求同时访问同一个热点数据，导致该热点数据在缓存失效期间被并发地访问，触发缓存击穿。
为了解决缓存击穿问题，可以采取以下策略：
- 设置热点数据永不过期或过期时间较长：对于一些热点数据，可以将其设置为永不过期，或者设置一个较长的过期时间，确保热点数据在缓存中可用，减少因为过期而触发的缓存击穿。
- 加互斥锁或分布式锁：在访问热点数据时，可以引入互斥锁或分布式锁，保证只有一个线程去访问后端服务或数据库，其他线程等待结果。当第一个线程获取到数据后，其他线程可以直接从缓存获取，避免多个线程同时访问后端服务，减轻压力。
- 限制并发访问：通过限制并发访问热点数据的请求量，可以控制请求的流量，避免过多请求同时访问热点数据。
4.缓存雪崩和缓存击穿的区别
缓存雪崩和缓存击穿是两种不同的缓存失效现象，它们在触发条件和影响范围上有所不同。
缓存雪崩（Cache Avalanche）：
- 触发条件：缓存雪崩是指在缓存系统中，大量的缓存键同时失效或过期，导致请求直接访问数据库或后端服务的现象。
- 影响范围：缓存雪崩会影响整个缓存系统，所有受影响的请求都会直接访问数据库或后端服务，导致数据库负载剧增，系统性能下降甚至崩溃。
缓存击穿（Cache Penetration）：
- 触发条件：缓存击穿是指在缓存系统中，某个热点数据失效或过期时，大量的请求同时访问该数据，导致请求直接访问数据库或后端服务的现象。
- 影响范围：缓存击穿通常只影响到热点数据，其他数据仍然可以从缓存中获取。只有在热点数据失效期间，才会触发大量请求访问数据库或后端服务。
主要区别：
- 触发条件不同：缓存雪崩是大量缓存键同时失效或过期，缓存击穿是针对某个热点数据失效或过期。
- 影响范围不同：缓存雪崩影响整个缓存系统，所有请求都受到影响；缓存击穿通常只影响到热点数据，其他数据仍可从缓存中获取。
- 对后端服务的影响不同：缓存雪崩会给后端服务带来巨大压力，导致性能下降甚至崩溃；缓存击穿只在热点数据失效期间对后端服务产生压力。
解决方法也不完全相同：
- 缓存雪崩的解决方法包括：合理设置缓存过期时间，引入热点数据永不过期、缓存预热、分布式缓存等策略。
- 缓存击穿的解决方法包括：设置热点数据永不过期或过期时间较长，加互斥锁或分布式锁，异步加载缓存等策略。
虽然缓存雪崩和缓存击穿都是缓存失效相关的问题，但它们的触发条件、影响范围和解决方法有所区别。
4.分布式锁
1.什么是分布式锁
随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！
通俗来讲:多个服务器,只能锁一个服务器,但是我们需要锁多个服务器
分布式锁主流的实现方案：
1. 基于数据库实现分布式锁
2. 基于缓存（Redis等）
3. 基于Zookeeper
每一种分布式锁解决方案都有各自的优缺点：
1. 性能：redis最高
2. 可靠性：zookeeper最高
这里，我们就基于redis实现分布式锁。
2.设置锁
只有当setnx返回1的时候才能进行操作
使用del释放锁
java代码
@GetMapping("/lock")
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
int 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.150.1:8080/redis/lock
但是这种方式有个很大的缺点,就是必须主动释放锁,当线程挂掉了无法主动释放所,此时就会出现问题,其他线程无法操作数据了,都会被卡死
3.设置过期时间
可以使用如下命令设置过期时间,这样就不会出现上面所说的问题
这样可以在代码中设置过期时间
Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", "111",10, TimeUnit.SECONDS);
但是此时还可能会出现锁的误删问题,比如线程一执行需要7秒,但是过期时间设置的是5秒,当执行到到第5秒的时候,锁就自动过期了,这个时候线程二拿到了锁,此时过了两秒之后,线程一手动释放锁,这个时候线程一释放的是线程二的锁,这个时候就会不符合预期
4.UUID防止误删
使用uuid标识不同的锁,释放锁的时候判断当前uuid和释放锁的uuid是否一致,如果一致才能进行释放
java代码
@GetMapping("/lock")
public void testLock() {
String uuid= UUID.randomUUID().toString();
//1获取锁，setne
Boolean lock = redisTemplate.opsForValue().setIfAbsent("lock", uuid,10, TimeUnit.SECONDS);
//2获取锁成功、查询num的值
if (lock) {
Object value = redisTemplate.opsForValue().get("num");
//2.1判断num为空return
if (StringUtils.isEmpty(value)) {
return;
}
//2.2有值就转成成int
int num = Integer.parseInt(value + "");
//2.3把redis的num加1
redisTemplate.opsForValue().set("num", ++num);
//2.4释放锁，del
if(uuid.equals(redisTemplate.opsForValue().get("lock"))){
redisTemplate.delete("lock");
}
} else {
//3获取锁失败、每隔0.1秒再获取
try {
Thread.sleep(100);
testLock();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}但是此时还会出现问题
线程一已经比较了uuid相同,要删除但是还没有删除,此时锁到了过期时间,锁自动释放,此时线程二拿到了锁,这时候线程一又把线程二的锁删除了.这个操作不具备原子性才发生了这个问题.
5.LUA保证原子性
使用LUA脚本实现原子性,使用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<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();
}
}
}
269
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
