您的位置: 首页  >  文章  >  redis（二）redis事务、主从复制以及缓存雪崩、穿透

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

分类: 文章 • 2024-03-16 18:31:58

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

文章目录

第五章Redis的事务

5.1 是什么

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

5.2 作用

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

5.3使用

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

  • 正常执行事务
    redis（二）redis事务、主从复制以及缓存雪崩、穿透

  • 放弃事务
    redis（二）redis事务、主从复制以及缓存雪崩、穿透

  • 编译型异常（代码有问题！ 命令有错！） ，事务中所有的命令都不会被执行（全体连坐）
    redis（二）redis事务、主从复制以及缓存雪崩、穿透

  • 运行时异常（1/0），如果事务队列中存在语法性，那么执行命令的时候，其他命令是可以正常执行的，错误命令抛出异常！（冤头债主）
    redis（二）redis事务、主从复制以及缓存雪崩、穿透

5.4 重点使用 watch监控

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

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

5.4.2Redis测监视测试

案例：

  • 初始化信用卡可用余额和欠额
  • 无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
  • 有加塞篡改
    测试多线程修改值 , 使用watch 可以当做redis的乐观锁操作！ redis（二）redis事务、主从复制以及缓存雪崩、穿透
  • unwatch
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
  • 一旦执行了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事务、主从复制以及缓存雪崩、穿透
    下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的
    关系：
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户
    端：
    redis（二）redis事务、主从复制以及缓存雪崩、穿透

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事务、主从复制以及缓存雪崩、穿透
redis（二）redis事务、主从复制以及缓存雪崩、穿透

  • 订阅多个，通配符*
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
  • 此章节简单了解即可，开发中不会用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事务、主从复制以及缓存雪崩、穿透
        主从复制，读写分离！ 80% 的情况下都是在进行读操作！减缓服务器的压力！架构中经常使用！ 一主二从！
        只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis！

7.2 主从复制的作用

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

7.3 怎么用

7.3.1 环境配置

  • 只配置从库，不用配置主库！
  • redis（二）redis事务、主从复制以及缓存雪崩、穿透
  • 修改配置文件细节操作
    拷贝多个redis.conf文件
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    开启daemonize yes
    Pid文件名字
    指定端口
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    Log文件名字
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    Dump.rdb名字
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透

7.3.2常用3招

7.3.2.1一主二仆

  • 默认情况下，每台Redis服务器都是主节点； 我们一般情况下只用配置从机就好了！
  • 认老大！ 一主 （79）二从（80，81）
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
  • 细节：
    主机可以写，从机不能写只能读！主机中的所有信息和数据，都会自动被从机保存！
    主机写：
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    从机不能写，只能读：
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
  • 测试：
    • 主机断开连接，从机依旧连接到主机的，但是没有写操作，这个时候，主机如果回来了，从机依旧可以直接获取到主机写的信息！
    • 如果是使用命令行，来配置的主从，这个时候如果从机断开连接之后重启了，就会变回主机！只要再次变为从机，立马就会从主机中获取值！

7.3.2.2薪火相传

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

7.3.2.3反客为主

  • SLAVEOF no one：使当前数据库通知与其他数据库的同步，转成主数据库。
    redis（二）redis事务、主从复制以及缓存雪崩、穿透

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事务、主从复制以及缓存雪崩、穿透

  • 正常主从演示
    原有的master挂了
    投票新选
    重新主从继续开工，info replication查查看
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
    投票后主机变成81了
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
  • 问题：如果之前的master重启回来，会不会双master冲突？
    • 答：不会，79回来后，变成了小弟了，81是新老大
      redis（二）redis事务、主从复制以及缓存雪崩、穿透
      redis（二）redis事务、主从复制以及缓存雪崩、穿透
  • 一组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事务、主从复制以及缓存雪崩、穿透

  • 2、编码测试：
    连接数据库
    操作命令
    断开连接！
    redis（二）redis事务、主从复制以及缓存雪崩、穿透
  • 常用的API
    String
    List
    Set
    Hash
    Zset

第九章Redis缓存穿透和雪崩（面试高频，工作常用）

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

9.1缓存穿透

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

9.1.1 解决方案

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

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

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

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

9.2缓存击穿

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

9.2.1 解决方案

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

9.3缓存雪崩

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

9.3.1 解决方案

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

相关推荐