Redis学习笔记2

视频学习链接https://www.bilibili.com/video/BV1S54y1R7SB

---

事务

Redis事务本质:一组命令的集合!一个事务中的所有命令都是被序列化的,在事务执行过程中,会按照顺序执行

一次性,顺序性,排它性,执行一些命令

Redis单条命令式保存原子性的,但是事务不保证原子性

所有的命令在事务中,并没有直接执行,只有发起执行命令的时候才会执行!Exec

Redis事务没有隔离级别的概念

redis的事务

• 开启事务(multi)
• 命令入队()
• 执行事务()

测试:

127.0.0.1:6379> multi  //开启事务
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 k2
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> exec   //执行事务
1) OK
2) OK
3) "k2"
4) OK

出现编译错误(命令有错),直接把事务丢弃,事务中的命令都不会执行

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> set k3
(error) ERR wrong number of arguments for 'set' command  //执行事务报错,所有命令都不会执行
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.  //存在错误,事务不会再执行了
127.0.0.1:6379> exec
(error) ERR EXEC without MULTI

主动丢弃事务,事务中的所有行动都不会执行

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> discard  //放弃事务
OK
127.0.0.1:6379> get k2 
(nil)

语法没错,运行时异常,除了异常的命令,其他命令都可以执行(不保证原子性)

127.0.0.1:6379> set k1 gg
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr k1
QUEUED
127.0.0.1:6379> get k1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> exec
1) (error) ERR value is not an integer or out of range  //gg不能被+1,没有执行
2) "gg"                                                 //别的命令执行了
3) OK
4) OK

---

监控

悲观锁

• 很悲观,认为什么时候都会出问题,无论做什么都会加锁

乐观锁

• 很乐观,认为什么时候都不会出问题,所有不会上锁,更新数据的时候去判断一下,在此期间是否有人修改过这个数据
• 获取version
• 更新的时候比较version

Redis的监视测试

127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> watch money //监视money对象
OK
127.0.0.1:6379> multi       //事务正常结束,数据期间没有发生变动,这个时候就正常执行成功
OK
127.0.0.1:6379> decrby money 20
QUEUED
127.0.0.1:6379> incrby out 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 20

测试多线程修改值,使用watch可以当做redis的乐观锁操作

另外一个线程

127.0.0.1:6379> get money 
"80"
127.0.0.1:6379> set money 1000
OK

当前线程

127.0.0.1:6379> watch money//监视money 
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
127.0.0.1:6379> exec  //执行之前,另外一个线程修改了我们的值,这个时候,就会导致事务执行失败
(nil)

处理办法:

127.0.0.1:6379> unwatch    //如果发现事务执行失败,就解锁
OK
127.0.0.1:6379> watch money  //获取最新的值,再次监视,select version
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
127.0.0.1:6379> exec          //对比监视的值是否发生变化,如果没有变化,那么可以执行成功,如果变化了就执行失败
1) (integer) 990
2) (integer) 30

---

Jedis

我们要使用java来操作Redis

jedis是redis官方推荐的java连接开发工具!使用java操作redis中间件,如果你要使用java操作redis,那么一定要对jedis十分熟悉

导入依赖

    
        redis.clients
        jedis
        3.2.0
    
    
    
        com.alibaba
        fastjson
        1.2.62
    

连接jedis

//new Jedis 对象
Jedis jedis=new Jedis("47.113.115.37",6379);
jedis.auth("123456");
//jedis 所有的命令就是我们之前学习的所有指令
System.out.println(jedis.ping());
        

Jedis处理事务

        Jedis jedis=new Jedis("47.113.115.37",6379);
        jedis.auth("123456");

        System.out.println(jedis.ping());
        jedis.flushDB();

        JSONObject jsonObject=new JSONObject();
        jsonObject.put("hello","world");
        jsonObject.put("name","kuangshen");

        //开启事务
        Transaction multi = jedis.multi();
        String result=jsonObject.toJSONString();

        try {
            multi.set("user1",result);
            multi.set("user2",result);
            int i=1/0;//代码抛出异常,事务执行失败
            multi.exec();//执行事务
        }catch (Exception e){
            multi.discard();//放弃事务
            e.printStackTrace();
        }finally {
            System.out.println(jedis.get("user1"));
            System.out.println(jedis.get("user2"));
            jedis.close();
        }

---

SpringBoot整合

SpringBoot操作数据:spring-data:jpa,jdbc,mongodb,redis

SpringData也是和SpringBoot同级别的

说明:在springboot2.x之后,原来使用的jedis被替换成lettuce

jedis:采用直连,多个线程操作的话,是不安全的,如果想要避免不安全,使用jedis pool连接池,像BIO模式

lettuce:采用netty,实例可以再多个线程中共享,不存在线程不安全的情况,可以减少线程数据,更像NIO模式

所有的redis操作,其实对于java开发人员来说,十分简单,更重要的要去理解redis的思想和每一种数据结构用处和作用场景

---

Redis.conf详解

工作中,要用配置来优化.

单位:

配置文件对大小写不敏感

包含:

就好比我们学习spring,import,include

网络:

是否绑定ip,如果注释就是所有ip都可以访问

保护模式

端口设置

运行方式是否为守护进程

以守护进程的方式运行,默认是no,我们要自己开启为yes

如果以后台方式运行,我们就需要指定一个pid进程文件

日志:

# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)
loglevel notice

# Specify the log file name. Also the empty string can be used to force
# Redis to log on the standard output. Note that if you use standard
# output for logging but daemonize, logs will be sent to /dev/null
logfile ""      //日志的文件位置名

数据库数目:

默认的数据库数目,默认是16个

显示logo:

是否总是显示logo,默认开启

快照:

持久化,在规定的时间内,执行了多少次操作,则会持久化到文件 .rdb .aof

redis是内存数据库,如果没有持久化,数据断电即失!

save 900 1   //在900秒内,至少有1个key进行了修改,我们及时进行持久化操作
save 300 10  //300秒,超过10个key修改,就持久化
save 60 10000 //在60秒内,超过1w次key修改,及时进程持久化

持久化如果出错,是否还继续工作

是否压缩rdb文件,需要消耗一些cpu资源

保存rdb文件的时候,进行错误的检查校验

rdb文件保存的地方,默认在当前文件夹

设置密码,默认是空的,设置密码后,连接redis需要密码

设置连接redis的最大客户端数目

redis配置最大的内存容量

内存满了后的处理策略(移除过期的key,报错,.....)

# volatile-lru :只对设置了过期时间的key进行LRU(默认值)
# allkeys-lru :删除LRU算法的key
# volatile-lfu 
# allkeys-lfu 
# volatile-random :随机删除即将过期的key
# allkeys-random :随机删除
# volatile-ttl :删除即将过期的
# noeviction :永不过期,返回错误
#

aof模式的配置

默认不开启aof模式,默认使用rdb方式持久化,在绝大部分的情况下,rdb完全够用

持久化的文件名字

1.每次修改都会sync,消耗性能

2.每秒执行一次sync,可能会丢失这1s的数据(默认)

3.不同步,操作系统自己同步数据,速度最快

---

Redis持久化

面试和工作,持久化是重点

redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失,所有redis提供了持久化功能

RDB

默认保存的文件名

我设置60秒修改5次就触发1次rdb操作

当前文件夹下有一个dump.rdb文件

将其删除

修改5次就生产

flushall后,立即产生一个dump.rdb文件

触发机制:

• save次数满足设定的规则
• 执行flushall命令
• 退出redis,也会产生rdb文件

备份就会自动生成一个dump.rdb文件

如何恢复rdb文件?

1.只需要将rdb文件放到我们redis启动目录就可以,redis启动的时候会自动检查dump.rdb恢复其中的数据

2.查看需要存在的位置

就是当前目录,所有默认的情况下就够用了(相当于自动快照)

优点:

1.适合大规模的数据恢复 dump.rdb

2.如果对数据的完整性不高

缺点:

1.需要一定的时间间隔,如果redis意外宕机,这个最后一次修改数据就没有了

2.fork进程的时候,会占用一定的内存空间

AOF(Append Only File)

将我们所有命令都记录下来,history,恢复的时候就把这个文件全部执行一遍

默认启动aof,要启动,就改为yes.

重启redis后立即生效

这个文件会记录我们所有写操作.

如果这个 aof 文件有错位，这时候 redis 是启动不起来的吗,

我们需要修复这个aof文件 redis 给我们提供了一个工具 redis-check-aof --fix

aof 默认就是文件的无限追加，文件会越来越大

如果 aof 文件大于 64m，太大了！ fork一个新的进程来将我们的文件进行重写

优点:

• 每一次修改都同步,文件的完整会更加好
• 每秒同步一次,可能会丢失一秒的数据
• 从不同步,效率最高

缺点:

• 相对于数据文件来说,aof远远大于rdb,修复的速度也比rdb慢
• aof运行效率比rdb慢,所有我们redis默认的配置是rdb

扩展：

1、RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2、AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始 的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重 写，使得AOF文件的体积不至于过大。

3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

4、同时开启两种持久化方式

• 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF 文件保存的数据集要比RDB文件保存的数据集要完整。
• RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者 建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有 AOF可能潜在的Bug，留着作为一个万一的手段。

5、性能建议

• 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够 了，只保留 save 900 1 这条规则。
• 如果Enable AOF ，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自 己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的最后将 rewrite 过程中产 生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite 的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重 写可以改到适当的数值。
• 如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也 减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据， 启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构

---

Redis发布订阅

Redis发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收信息.

微信,微博,关注系统

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

订阅kuangshenshuo,kuangshenshuo发布消息就会显示出来

发了一个信息给kuangshenshuo

---

Redis主从复制

概念:

主从复制,是指将一台redis服务器的数据,复制到其他的redis服务器.前者为主节点,后者为从节点,数据的复制是单向的,只能由主节点到从节点.主节点以写为主,从节点以读为主

默认情况下,每台redis服务器都是主节点

且主节点可以有多个从节点,但是从节点只能有一个主节点.

主从复制的作用:

• 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余
• 故障恢复:当主结点出现问题时,可以由从节点提供服务,实现快速的故障恢复,实际上是一种服务的冗余
• 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,从节点提供读服务,分担服务器负载,尤其在写少读多的场景下,通过多个从节点分担读负载,可以大大提高redis服务器的并发量
• 高可用(集群)基石:除了上述作用外,主从复制还有哨兵和集群能够实施的基础,因此说主从复制是redis高可用的基础

一般来说,要将redis运用在工程项目中,只使用一台redis是万万不能的(宕机),原因如下

1.从结构上,单个redis服务器会发送单点故障,并且一台服务器需要处理所有的请求负载,压力太大

2.从容量上,单个服务器内存容量有限,就算一台redis服务器的内存容量为256g,也不能将所有内存用作redis存储内存,一般来说redis最大使用内存不应该超过20g.

主从复制,读写分离.80%的情况下都是在进行读操作,减缓服务器的压力.最低配一主二从

在公司中,主从复制是必须使用的,因为在真实的项目中不可能单机使用redis

环境配置

只配置从库,不用配置主库

127.0.0.1:6379> info replication//查看当前库的信息
# Replication
role:master    //角色,当前是主机
connected_slaves:0  //从机数目
master_replid:33a4b2e54594f78449412f27d4222d5f887633ec
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

复制了3个配置文件,修改了对应的信息

1.端口

2.pid名字

3.log文件名字

4.dump.rdb名字

修改完毕之后,启动3个集群,通过进程信息查看!

---

一主二从

默认情况下,每台redis服务器都是主节点;我们一般情况下只要配置从机就好了

认老大!  一主(79)二从(80,81)

从机配置

127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:1
master_link_down_since_seconds:1594024869
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:d24109db1cef5dc56a98e5f202e63728ba1aa8fe
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

防火墙开放:从机端口

如果主机设置了密码,那么要修改从机配置文件,设置连接主机的密码:

例如vim redis80.conf  查找: masterauth,设置: masterauth 主机密码 ,然后保存

从机想要连接主机,主机如果有密码,是需要密码的

127.0.0.1:6380> info replication
# Replication
role:slave  //从机
master_host:127.0.0.1
master_port:6379
master_link_status:up  //如果为down,那么表示连接失败,可能是防火墙,安全组,或者主机设了密码,从机配置文件没有设置主机密码/设置的主机密码错误
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:28
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:2d243055bc00df40f3523e437124e96821ee469b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:28
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:28

主机信息:

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2   //目前两台从机连接了该主机
slave0:ip=127.0.0.1,port=6380,state=online,offset=938,lag=1  //从机信息,ip地址,端口号,状态等
slave1:ip=127.0.0.1,port=6381,state=online,offset=938,lag=1
master_replid:2d243055bc00df40f3523e437124e96821ee469b
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:938
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:938

真实的主从配置应该在配置文件中配置,呢样是永久的,我们这里用命令是临时的.

127.0.0.1:6380> keys *//查看从机的key
1) "name"
2) "b"
3) "a"
4) "c"
127.0.0.1:6380> flushdb
(error) READONLY You can't write against a read only replica.//从机不能写
127.0.0.1:6380> keys *  //主机清空后,从机中的key也被清空
(empty array)

主机清空

127.0.0.1:6379> flushdb
OK

主机断开,从机依旧连接主机,但是,没有写操作,如果主机再次开启,主机写的信息从机也能查询到.

从机断开,如果是使用命令配置主从,从机再次连接,那么从机就不会连接主机,它默认是主机.

从机断开的时候,如果主机写了信息,从机再连接,从机还能查询到它断开时候主机写的信息,连接之后,主机写了的信息立马就会从主机复制到从机中.

复制原理

slave启动成功连接master后会发送一个sync同步命令

master接到命令,启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕后,master将传送整个数据文件到slave,并完成一次完全同步.

全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中.

增量复制:master继续将新的所有收集到的修改命令依次传给slave,完成同步

但是只要是重新连接master,一次完全同步(全量复制)将被自动执行!我们的数据一定可以在从机中看到!

层层链路

上一个M链接下一个S

如果79宕机了,我们手动操作使用命令SLAVEOF no one将80设置为新主机,其他的节点就可以手动连接到这个新的主机节点.

---

哨兵模式

概述:

redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行.

原理是哨兵通过发生命令,等待redis服务器的响应,从而健康运行多个redis实例

哨兵有两个作用:

• 通过发生命令,让redis服务器返回健康其运行状态,包括主服务器和从服务器
• 当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机.

一个哨兵进程对服务器进行监控,如果哨兵也宕机,那就好出问题

我们可以使用多个哨兵,互相监控.

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认 为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一 定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。 切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线

测试:

要实现哨兵模式要创建配置文件并允许redis-sentinel

[root@izwz9jbyc3h7foxlon2jfvz home]# vim sentinel.conf  //编写配置文件
[root@izwz9jbyc3h7foxlon2jfvz home]# redis-sentinel sentinel.conf   //根据自己的配置,运行哨兵进程

配置信息:

我的6379,6380,6381的配置文件都设置了连接主机密码123456.最开始6381当主机,6379,6380当从机,这两个配置文件设置了主机ip和主端口.

我的配置文件:

sentinel monitor myredis 127.0.0.1 6380 1  //主机位6380
sentinel auth-pass myredis 123456    //密码位123456,6379,6380,6381的配置文件都要设置连接主机的密码为123456

启动后,再打开配置文件,配置文件被重新编写,增加了部分信息.

当前主机是6381,从机为6379和6380

我现在关闭6381

然后配置文件自动发生变化,主机变成6380,从机变成6381和6379,目前6381还没连接上,6381连接上后它就是从机了,不会变主机,除非6380断开,再次随机选取主机

主机6381连接失败,它自己选取了6380当新的主机,我再连接6381,6381就成了6380的从机.

---

Redis缓存穿透和雪崩

 

1.缓存穿透(查不到)

就是在redis上查不到,都去差数据库,数据库的压力突然变大.

用户想要查询一个数据,发现redis内存数据库没有,也就是缓存没有命中于是向持久层数据库查询,发现也没有,于是本次查询失败.如果很多个用户查询,缓存都没有命中,都去查持久层,就会对持久层数据库造成很大的压力.

解决方案:

布隆过滤器

布隆过滤器是一种数据结构,对所有可能的查询的参数以hash形式存储,再控制层进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力

缓存空对象

当存储层不命中后,即使返回的空对象也将其缓存起来,同时会设置一个过期时间,之后再访问这个数据就会从缓存中获取,保护后端数据源

但是会产生2个问题:

1. 如果空值能够被缓存起来门面意味着要更多的空间存储更多的键,因为可能产生很多的空值的键
2. 即使对空值设置了过期时间,还是会存在缓存层和存储层的数据有一段时间窗口不一致,这对于需要保持一致性的业务会产生影响

2.缓存击穿(量太大,缓存过期)

缓存击穿,是指一个key非常热点,在不停的扛着大并发,大并发集中对这个点进行访问,当这个key在失效的瞬间,持续的大并发就击破缓存,直接请求数据库,使数据库瞬间压力过大

解决方案:

设置数据永不过期

从缓存层来看,没有设置过期时间,所以不会出现热点key过期后产生的问题

加互斥锁

分布式锁:使用分布式锁,保证对于每个key同时只有一个线程去查询后端服务,其他线程没有获得分布式锁的权限,因此只需要等待即可,这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考验很大.

3.缓存雪崩

缓存雪崩,指在一段时间,缓存集中过期失效,redis宕机

产生雪崩的原因之一,如果在双11的0点,一大波抢购,产生大量缓存,假设缓存一个小时,那么在1点种的时候,这批商品的缓存就都过期.如果再次查询这批商品,那么都会直接查询数据库,对于数据库,就可能产生周期性的压力波峰.于是所有的请求都到达存储层,存储层的调用量也暴增,可能造成存储层宕机

其中集中过期,倒不是非常致命,比较致命的缓存雪崩,是缓存服务器某个节点宕机或断网,可能瞬间将数据库压垮.

解决方案:

redis高可用

这个思想的含义是,既然redis有可能挂掉,呢就多设几台redis,这样一台挂掉之后其他的还可以继续工作,期间就是redis集群的搭建.

限流降级

这个解决方案的思想是,在缓存失效后,通过加索或者队列来控制读数据库写缓存的线程数,比如对某个key只允许一个线程查询数据和写缓存,其他线程等待.

数据预热

数据加热含义就是在正式部署前,我先把可能的数据先预先访问一遍,这样部分可能大量访问的数据就加载到缓存中,即使发生大并发前手动触发加载缓存不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀.