redis(二)redis事务、主从复制以及缓存雪崩、穿透

redis系列笔记
Redis(一)Redis_NoSQL入门概述、Redis的安装、redis数据类型介绍以及Redis的持久化.
redis(二)redis事务、主从复制以及缓存雪崩、穿透.

文章目录

  • 第五章Redis的事务
    • 5.1 是什么
    • 5.2 作用
    • 5.3使用
    • 5.4 重点使用 watch监控
      • 5.4.1 悲观锁/乐观锁/CAS(Check And Set)
      • 5.4.2Redis测监视测试
    • 5.5 事务三阶段
    • 5.6 事务三特性
  • 第六章Redis的发布订阅
    • 6.1是什么
    • 6.2命令
    • 6.3测试
  • 第七章redis的主从复制
    • 7.1是什么
    • 7.2 主从复制的作用
    • 7.3 怎么用
      • 7.3.1 环境配置
      • 7.3.2常用3招
        • 7.3.2.1一主二仆
        • 7.3.2.2薪火相传
        • 7.3.2.3反客为主
    • 7.4 复制原理
    • 7.5 哨兵模式(setinel)
      • 7.5.1是什么
      • 7.5.2怎么玩
      • 7.5.3 哨兵模式优缺点
    • 7.6 复制的缺点
  • 第八章Redis的Java客户端Jedis
  • 第九章Redis缓存穿透和雪崩(面试高频,工作常用)
    • 9.1缓存穿透
      • 9.1.1 解决方案
    • 9.2缓存击穿
      • 9.2.1 解决方案
    • 9.3缓存雪崩
      • 9.3.1 解决方案

第五章Redis的事务

5.1 是什么

  • 可以执行多个命令,Redis 事务本质:一组命令的集合! 一个事务中的所有命令都会被序列化,在事务执行过程的中,会按
    照顺序执行!按顺序的串行化执行而不会被其他命令插入,不许加塞

5.2 作用

  • 一个队列中,一次性、顺序性、排他性地执行一系列命令!

5.3使用

  • 通过MULTI命令进入Redis事务。通过EXEC执行。

  • 正常执行事务
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第1张图片

  • 放弃事务
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第2张图片

  • 编译型异常(代码有问题! 命令有错!) ,事务中所有的命令都不会被执行(全体连坐)
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第3张图片

  • 运行时异常(1/0),如果事务队列中存在语法性,那么执行命令的时候,其他命令是可以正常执行的,错误命令抛出异常!(冤头债主)
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第4张图片

5.4 重点使用 watch监控

5.4.1 悲观锁/乐观锁/CAS(Check And Set)

  • 悲观锁
    • 顾名思义,每次去拿数据的时候都被认为别人会修改,所以每次在拿数据的时候都会被锁上,这样别人想拿这个数据就会block直到它拿到锁,传统的关系型数据库里边就用到了很多这种锁机制,比如行锁、表锁等,读锁、写锁等,都是在做操作之前先锁上。
    • 很悲观,认为什么时候都会出问题,无论做什么都会加锁!
  • 乐观锁
    • 每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号version等机制。乐观锁适用于多度的应用类型,这样可以提高吞吐量。
    • 乐观锁策略:提交版本必须大于记录当前版本才能执行更新。
    • 很乐观,认为什么时候都不会出问题,所以不会上锁! 更新数据的时候去判断一下,在此期间是否有人修改过这个数据,获取version,更新的时候比较 version
    • 工作中一般用乐观锁

5.4.2Redis测监视测试

案例:

  • 初始化信用卡可用余额和欠额
  • 无加塞篡改,先监控再开启multi,保证两笔金额变动在同一个事务内
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第5张图片
  • 有加塞篡改
    测试多线程修改值 , 使用watch 可以当做redis的乐观锁操作! redis(二)redis事务、主从复制以及缓存雪崩、穿透_第6张图片
  • unwatch
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第7张图片
  • 一旦执行了exec,之前加的监控锁都会被取消掉
  • 小结
    • Watch指令,类似乐观锁,事务提交时,如果Key的值已经被别的客户端改变,比如某个list已经被别的客户端push/pop过了,整个事务队列都不会被执行。
    • 通过WATCH命令在事务执行之前监控了多个keys,倘若在WATCH之后有任何key的值的变化,EXEC命令执行的事务都将被放弃,同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

5.5 事务三阶段

  • 开启:以MULTI开始一个事务
  • 入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面。
  • 执行:由EXEC命令触发事务

5.6 事务三特性

  • 单独的隔离操作:事务中的所有命令都会被序列化、按顺序地执行。事务在执行的构成中,不会被其他客户端发送来的命令请求所打断。
  • 没有隔离级别的概念:队列中的命令没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际执行,也就不存在“事务内的查询要看到事务里的更新,在事务外查询不能看到”这个让人万分头痛的问题。
  • 不保证原子性:redis同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚。

第六章Redis的发布订阅

6.1是什么

  • Redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。微信、
    微博、关注系统!
  • Redis 客户端可以订阅任意数量的频道。
  • 订阅/发布消息图:
    第一个:消息发送者, 第二个:频道 第三个:消息订阅者!
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第8张图片
    下图展示了频道 channel1 , 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的
    关系:
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第9张图片
    当有新消息通过 PUBLISH 命令发送给频道 channel1 时, 这个消息就会被发送给订阅它的三个客户
    端:
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第10张图片

6.2命令

  • PSUBSCRIBE pattem [pattem…]:订阅一个或多个符合给定模式的频道
  • PUBSUB subcommand [argument [argument…]]:查看订阅与发布系统状态。
  • PUBLISH channel message:将信息发送到指定的频道。
  • PUNSUBSCRIBE [pattem [pattem…]]:退订所有给定模式的频道。
  • SUBSCRIBE channel [channel…]:订阅给定的一个或多个频道的信息。
  • UNSUBSCRIBE [channel [channel…]]:指退订给定的频道。

6.3测试

redis(二)redis事务、主从复制以及缓存雪崩、穿透_第11张图片
redis(二)redis事务、主从复制以及缓存雪崩、穿透_第12张图片

  • 订阅多个,通配符*
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第13张图片
    在这里插入图片描述
  • 此章节简单了解即可,开发中不会用redis做消息中间件

第七章redis的主从复制

7.1是什么

  • 主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master/leader),后者称为从节点(slave/follower);数据的复制是单向的,只能由主节点到从节点。Master以写为主,Slave 以读为主。
  • 默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点
  • 特别注意:
    • 一般来说,要将Redis运用于工程项目中,只使用一台Redis是万万不能的(宕机),原因如下:
      • 1、从结构上,单个Redis服务器会发生单点故障,并且一台服务器需要处理所有的请求负载,压力较
        大;
      • 2、从容量上,单个Redis服务器内存容量有限,就算一台Redis服务器内存容量为256G,也不能将所有
        内存用作Redis存储内存,一般来说,单台Redis最大使用内存不应该超过20G。
        电商网站上的商品,一般都是一次上传,无数次浏览的,说专业点也就是"多读少写"。
        对于这种场景,我们可以使如下这种架构:
        redis(二)redis事务、主从复制以及缓存雪崩、穿透_第14张图片
        主从复制,读写分离! 80% 的情况下都是在进行读操作!减缓服务器的压力!架构中经常使用! 一主二从!
        只要在公司中,主从复制就是必须要使用的,因为在真实的项目中不可能单机使用Redis!

7.2 主从复制的作用

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

7.3 怎么用

7.3.1 环境配置

  • 只配置从库,不用配置主库!
  • redis(二)redis事务、主从复制以及缓存雪崩、穿透_第15张图片
  • 修改配置文件细节操作
    拷贝多个redis.conf文件
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第16张图片
    开启daemonize yes
    Pid文件名字
    指定端口
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第17张图片
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第18张图片
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第19张图片
    Log文件名字
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    Dump.rdb名字
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

7.3.2常用3招

7.3.2.1一主二仆

  • 默认情况下,每台Redis服务器都是主节点; 我们一般情况下只用配置从机就好了!
  • 认老大! 一主 (79)二从(80,81)
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第20张图片
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第21张图片
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第22张图片
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第23张图片
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第24张图片
  • 细节:
    主机可以写,从机不能写只能读!主机中的所有信息和数据,都会自动被从机保存!
    主机写:
    在这里插入图片描述
    从机不能写,只能读:
    在这里插入图片描述
  • 测试:
    • 主机断开连接,从机依旧连接到主机的,但是没有写操作,这个时候,主机如果回来了,从机依旧可以直接获取到主机写的信息!
    • 如果是使用命令行,来配置的主从,这个时候如果从机断开连接之后重启了,就会变回主机!只要再次变为从机,立马就会从主机中获取值!

7.3.2.2薪火相传

  • 上一个Slave可以是下一个slave的Master,slave同样可以接受其他slaves的连接和同步请求,那么该slave作为链条中下一个的master,可以有效减轻master的写压力(去中心化
  • 只要角色是从机(或者其上有主机),不管他连接了多少从机,角色不变
  • 中途变更转向:会清楚之前的数据,重新建立拷贝最新的。
  • slaveof 新主库IP 新主库端口

7.3.2.3反客为主

  • SLAVEOF no one:使当前数据库通知与其他数据库的同步,转成主数据库。
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第25张图片

7.4 复制原理

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

7.5 哨兵模式(setinel)

7.5.1是什么

  • 主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel(哨兵) 架构来解决这个问题。
  • 反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库

7.5.2怎么玩

  • 1调整结构,6379带着80、81
  • 2自定义的/myredis目录下新建sentinel.conf文件,名字决不能错。
  • 3配置哨兵。填写内容:
    sentinel monitor被监控数据库名字(自己起名字)127.0.0.1 6379 1
    上面最后一个数字1,表示主机挂掉后slave投票看让谁接替成为主机,得票数多的成为主机
  • 启动哨兵
    Redis-sentinel /myredis/sentinel.conf
    上述目录依照各自的实际情况配置,可能目录不同

redis(二)redis事务、主从复制以及缓存雪崩、穿透_第26张图片

  • 正常主从演示
    原有的master挂了
    投票新选
    重新主从继续开工,info replication查查看
    在这里插入图片描述
    投票后主机变成81了
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第27张图片
  • 问题:如果之前的master重启回来,会不会双master冲突?
    • 答:不会,79回来后,变成了小弟了,81是新老大
      redis(二)redis事务、主从复制以及缓存雪崩、穿透_第28张图片
      redis(二)redis事务、主从复制以及缓存雪崩、穿透_第29张图片
  • 一组sentinel能同时监控多个Master

7.5.3 哨兵模式优缺点

  • 优点:
    1、哨兵集群,基于主从复制模式,所有的主从配置优点,它全有
    2、 主从可以切换,故障可以转移,系统的可用性就会更好
    3、哨兵模式就是主从模式的升级,手动到自动,更加健壮!
  • 缺点:
    1、Redis 不好在线扩容的,集群容量一旦到达上限,在线扩容就十分麻烦!
    2、实现哨兵模式的配置其实是很麻烦的,里面有很多选择!

7.6 复制的缺点

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

第八章Redis的Java客户端Jedis

  • 我们要使用 Java 来操作 Redis
  • 什么是Jedis :是 Redis 官方推荐的 java连接开发工具! 使用Java 操作Redis 中间件
  • 测试:
  • 1、导入对应的依赖

redis(二)redis事务、主从复制以及缓存雪崩、穿透_第30张图片

  • 2、编码测试:
    连接数据库
    操作命令
    断开连接!
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第31张图片
  • 常用的API
    String
    List
    Set
    Hash
    Zset

第九章Redis缓存穿透和雪崩(面试高频,工作常用)

  • Redis缓存的使用,极大的提升了应用程序的性能和效率,特别是数据查询方面。但同时,它也带来了一
    些问题。其中,最要害的问题,就是数据的一致性问题,从严格意义上讲,这个问题无解。如果对数据
    的一致性要求很高,那么就不能使用缓存。
  • 另外的一些典型问题就是,缓存穿透、缓存雪崩和缓存击穿。目前,业界也都有比较流行的解决方案。
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第32张图片

9.1缓存穿透

  • 缓存穿透的概念很简单,用户想要查询一个数据,发现redis内存数据库没有,也就是缓存没有命中,于是向持久层数据库查询。发现也没有,于是本次查询失败。当用户很多的时候,缓存都没有命中(秒杀!),于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力,这时候就相当于出现了缓存穿透。

9.1.1 解决方案

  • 1.布隆过滤器
    对所有可能查询的参数以hash形式存储,在控制层先进行校验,不符合则丢弃,从而避免了对底层存储系统的查询压力;
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第33张图片

  • 2.缓存空对象
    当存储层不命中后,即使返回的空对象也将其缓存起来,同时会设置一个过期时间,之后再访问这个数据将会从缓存中获取,保护了后端数据源;
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第34张图片

  • 但是这种方法会存在两个问题:

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

9.2缓存击穿

  • 这里需要注意和缓存击穿的区别,缓存击穿,是指一个key非常热点,在不停的扛着大并发,大并发集中对这一个点进行访问,当这个key在失效的瞬间,持续的大并发就穿破缓存,直接请求数据库,就像在一个屏障上凿开了一个洞。
  • 当某个key在过期的瞬间,有大量的请求并发访问,这类数据一般是热点数据,由于缓存过期,会同时访
    问数据库来查询最新数据,并且回写缓存,会导使数据库瞬间压力过大。

9.2.1 解决方案

  • 设置热点数据永不过期
    从缓存层面来看,没有设置过期时间,所以不会出现热点 key 过期后产生的问题。
  • 加互斥锁
    分布式锁:使用分布式锁,保证对于每个key同时只有一个线程去查询后端服务,其他线程没有获得分布
    式锁的权限,因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁,因此对分布式锁的考
    验很大。
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第35张图片

9.3缓存雪崩

  • 缓存雪崩,是指在某一个时间段,缓存集中过期失效。Redis 宕机!
  • 产生雪崩的原因之一,比如在写本文的时候,马上就要到双十二零点,很快就会迎来一波抢购,这波商品时间比较集中的放入了缓存,假设缓存一个小时。那么到了凌晨一点钟的时候,这批商品的缓存就都过期了。而对这批商品的访问查询,都落到了数据库上,对于数据库而言,就会产生周期性的压力波峰。于是所有的请求都会达到存储层,存储层的调用量会暴增,造成存储层也会挂掉的情况。
    redis(二)redis事务、主从复制以及缓存雪崩、穿透_第36张图片
  • 其实集中过期,倒不是非常致命,比较致命的缓存雪崩,是缓存服务器某个节点宕机或断网。因为自然
    形成的缓存雪崩,一定是在某个时间段集中创建缓存,这个时候,数据库也是可以顶住压力的。无非就
    是对数据库产生周期性的压力而已。而缓存服务节点的宕机,对数据库服务器造成的压力是不可预知
    的,很有可能瞬间就把数据库压垮。

9.3.1 解决方案

  • 1.redis高可用
    这个思想的含义是,既然redis有可能挂掉,那我多增设几台redis,这样一台挂掉之后其他的还可以继续工作,其实就是搭建的集群。(异地多活!)
  • 2.限流降级(在SpringCloud讲解过!)
    这个解决方案的思想是,在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。
  • 3.数据预热
    数据加热的含义就是在正式部署之前,我先把可能的数据先预先访问一遍,这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀。

你可能感兴趣的:(redis)