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执行。
-
正常执行事务
-
放弃事务
-
编译型异常（代码有问题！ 命令有错！） ，事务中所有的命令都不会被执行（全体连坐）
-
运行时异常（1/0），如果事务队列中存在语法性，那么执行命令的时候，其他命令是可以正常执行的，错误命令抛出异常！（冤头债主）
5.4 重点使用 watch监控
5.4.1 悲观锁/乐观锁/CAS(Check And Set)
- 悲观锁
- 顾名思义，每次去拿数据的时候都被认为别人会修改，所以每次在拿数据的时候都会被锁上，这样别人想拿这个数据就会block直到它拿到锁，传统的关系型数据库里边就用到了很多这种锁机制，比如行锁、表锁等，读锁、写锁等，都是在做操作之前先锁上。
- 很悲观，认为什么时候都会出问题，无论做什么都会加锁！
- 乐观锁
- 每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号version等机制。乐观锁适用于多度的应用类型，这样可以提高吞吐量。
- 乐观锁策略：提交版本必须大于记录当前版本才能执行更新。
- 很乐观，认为什么时候都不会出问题，所以不会上锁！ 更新数据的时候去判断一下，在此期间是否有人修改过这个数据，获取version，更新的时候比较 version
- 工作中一般用乐观锁
5.4.2Redis测监视测试
案例：
- 初始化信用卡可用余额和欠额
- 无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内
- 有加塞篡改
测试多线程修改值 , 使用watch 可以当做redis的乐观锁操作！
- unwatch
- 一旦执行了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 客户端可以订阅任意数量的频道。
- 订阅/发布消息图：
第一个：消息发送者， 第二个：频道 第三个：消息订阅者！
下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的
关系：
当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户
端：
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的主从复制
7.1是什么
- 主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower)；数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave 以读为主。
- 默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点
- 特别注意：
- 一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的（宕机），原因如下：
- 1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较
大； - 2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有
内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。
电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"多读少写"。
对于这种场景，我们可以使如下这种架构：
主从复制，读写分离！ 80% 的情况下都是在进行读操作！减缓服务器的压力！架构中经常使用！ 一主二从！
只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis！
- 1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较
- 一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的（宕机），原因如下：
7.2 主从复制的作用
- 1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
- 2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
- 3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
- 4、高可用（集群）基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
7.3 怎么用
7.3.1 环境配置
- 只配置从库，不用配置主库！
- 修改配置文件细节操作
拷贝多个redis.conf文件
开启daemonize yes
Pid文件名字
指定端口
Log文件名字
Dump.rdb名字
7.3.2常用3招
7.3.2.1一主二仆
- 默认情况下，每台Redis服务器都是主节点； 我们一般情况下只用配置从机就好了！
- 认老大！ 一主 （79）二从（80，81）
- 细节：
主机可以写，从机不能写只能读！主机中的所有信息和数据，都会自动被从机保存！
主机写：
从机不能写，只能读：
- 测试：
- 主机断开连接，从机依旧连接到主机的，但是没有写操作，这个时候，主机如果回来了，从机依旧可以直接获取到主机写的信息！
- 如果是使用命令行，来配置的主从，这个时候如果从机断开连接之后重启了，就会变回主机！只要再次变为从机，立马就会从主机中获取值！
7.3.2.2薪火相传
- 上一个Slave可以是下一个slave的Master，slave同样可以接受其他slaves的连接和同步请求，那么该slave作为链条中下一个的master，可以有效减轻master的写压力（去中心化）
- 只要角色是从机（或者其上有主机），不管他连接了多少从机，角色不变
- 中途变更转向：会清楚之前的数据，重新建立拷贝最新的。
- slaveof 新主库IP 新主库端口
7.3.2.3反客为主
- SLAVEOF no one：使当前数据库通知与其他数据库的同步，转成主数据库。
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
上述目录依照各自的实际情况配置，可能目录不同
- 正常主从演示
原有的master挂了
投票新选
重新主从继续开工，info replication查查看
投票后主机变成81了
- 问题：如果之前的master重启回来，会不会双master冲突？
- 答：不会，79回来后，变成了小弟了，81是新老大
- 答：不会，79回来后，变成了小弟了，81是新老大
- 一组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、导入对应的依赖
- 2、编码测试：
连接数据库
操作命令
断开连接！
- 常用的API
String
List
Set
Hash
Zset
第九章Redis缓存穿透和雪崩（面试高频，工作常用）
- Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一
些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据
的一致性要求很高，那么就不能使用缓存。 - 另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案。
9.1缓存穿透
- 缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中（秒杀！），于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。
9.1.1 解决方案
-
1.布隆过滤器
对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力；
-
2.缓存空对象
当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源；
-
但是这种方法会存在两个问题：
- 如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键；
- 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。
9.2缓存击穿
- 这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。
- 当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访
问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。
9.2.1 解决方案
- 设置热点数据永不过期
从缓存层面来看，没有设置过期时间，所以不会出现热点 key 过期后产生的问题。 - 加互斥锁
分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布
式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考
验很大。
9.3缓存雪崩
- 缓存雪崩，是指在某一个时间段，缓存集中过期失效。Redis 宕机！
- 产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。
- 其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然
形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的。无非就
是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知
的，很有可能瞬间就把数据库压垮。
9.3.1 解决方案
- 1.redis高可用
这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。（异地多活！） - 2.限流降级（在SpringCloud讲解过！）
这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。 - 3.数据预热
数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。