邯郸论坛网站建设,前端工程师是做网站,表格制作教程 步骤,学摄影的网站有哪些目录 前言课程目录一、Redis持久化1.1 RDB快照#xff08;Snapshot#xff09;#xff1a;二进制文件基本介绍开启/关闭方式触发方式bgsave的写时复制#xff08;COW#xff0c;Copy On Write#xff09;机制优缺点 1.2 AOF#xff08;append-only file#xff09;Snapshot二进制文件基本介绍开启/关闭方式触发方式bgsave的写时复制COWCopy On Write机制优缺点 1.2 AOFappend-only file将读写命令记录下来方便回放基本介绍开启/关闭方式触发方式AOF重写优缺点 1.3 RDB和AOF对比怎么选1.4 Redis4.0 混合持久化AOF RDB基本介绍开启/关闭方式混合持久化aof文件内容 1.5 Redis数据生产备份策略 二、Redis主从架构——基础2.1 主从架构搭建2.2 Redis主从工作原理全量同步业务流程图增量同步业务流程图主从复制风暴代码实战 三、Redis主从架构——哨兵高可用架构3.1 Redis哨兵架构搭建3.2 哨兵架构高可用工作原理3.3 代码实战 学习总结 前言
课程目录
一、Redis持久化
【持久化】这个单词我想大家都不陌生吧。什么是持久化我们知道Redis的数据是存储在内存里面的所以在Redis这里其实是指把内存中的数据通过一些策略写到磁盘中方便因为宕机、或者重启Redis服务的时候再次把数据加载到内存中。 那么Redis中持久化策略方式有哪些呢其实主要的方式有如下三种让我们来看看吧
1.1 RDB快照Snapshot二进制文件
基本介绍
在默认情况下 Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。PS该持久化策略是默认的策略当然不排除在随后的版本中改了
开启/关闭方式 开启/关闭方式进入程序的目录修改redis.conf配置文件。开启/关闭RDB只需要将所有的save保存策略打开/注释掉即可 触发方式
RDB快照生成的触发方式有两种。一种是通过设置策略当满足条件的时候自动触发另一种当然是手动触发了。
我们先来说一下【自动触发】的方式。自动触发的方式就是按照Redis提供给我们的语法在redis.conf里面增加触发策略。设置规则如下 语法save seconds changes [seconds changes ...] 解释在【N 秒内数据集至少有 M 个改动】这一条件被满足时自动持久化一次 举个例子设置一条策略【在60秒内有1000个改动时自动持久化一次】。设置如下 save 60 1000 // 关闭RDB只需要将所有的save保存策略注释掉即可 至于手动触发方式则是进入redis客户端执行命令save或bgsave就可以生成dump.rdb文件每次命令执行都会将所有redis内存快照到一个新的.rdb文件里并覆盖原有.rdb快照文件。 save是同步执行生成rdb文件的操作执行时不会处理外部的命令bgsave则是异步执行生成操作会同时处理外部命令。
bgsave的写时复制COWCopy On Write机制
Redis借助操作系统的写时复制技术Copy On Write在生成快照的同时依然可以正常处理写命令。简单来说bgsave子进程是由主线程fork出来的所以可以共享主线程内存的所有数据。bgsave子进程运行后开始读取主线程的内存数据并把他们他们写入.rdb文件。此时如果主线程对这些数据也都是读操作那主线程跟子进程之间肯定没有影响若此时主线程需要修改一块数据那么这块数据会被复制一份生成该数据的副本。然后bgsave子进程会把这个副本数据写入.rdb文件中而在这个过程中主线程仍然可以直接修改原来的数据。 save与bgsave对比
命令savebgsaveIO类型同步异步是否阻塞redis其他命令是否。不过在生成子进程执行调用函数时会有短暂阻塞复杂度O(n)O(n)优点不会消耗额外内存不会阻塞客户端命令缺点阻塞客户端命令需要fork一个子进程消耗额外内存
上面配置的【自动触发】生成.rdb文件的策略后台使用的就是bgsave方式
优缺点
优点是由于是二进制文件所以Redis重启的时候恢复速度快 缺点是容易丢失数据为什么看下面【AOF】策略的介绍
1.2 AOFappend-only file将读写命令记录下来方便回放
基本介绍
看了上面的【RDB策略】不知道大家有没有感觉或者意识到什么。那就是这种策略其实看起来有点“苛刻”它的数据安全性并不靠谱 比如【在60秒内有1000个改动时自动持久化一次】的策略之下万一我在做第1000个改动的时候服务器宕机了那不是丢掉了前面999个操作了吗 所以快照功能并不是非常耐久durable的。 如果 Redis 因为某些原因而造成故障停机那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。不过从1.1版本开始Redis增加了一种完全耐久的持久化方式 AOF持久化将修改的每一条指令记录进文件appendonly.aof文件中先写入os cache每隔一段时间fsync到磁盘。 比如执行命令set zhuge 666.aof文件里会记录如下数据这是一种resp协议格式数据我在下面写上注释给大家翻译一下什么意思
*3 # 星号后面的数字表示执行的命令有多少个参数
$3 # 美元符号后面的数字代表这个参数有几个字符
set
$5 # 美元符号后面的数字代表这个参数有几个字符
zhuge
$3 # 美元符号后面的数字代表这个参数有几个字符
666注意如果执行带过期时间的set命令aof文件里记录的是并不是执行的原始命令而是记录key过期的时间戳。比如执行set tuling 888 ex 1000对应aof文件里记录如下
*3
$3
set
$6
tuling
$3
888
*3
$9
PEXPIREAT
$6
tuling
$13
1604249786301开启/关闭方式 开启/关闭方式进入程序的目录修改redis.conf配置文件。开启/关闭aof只需要修改如下参数 # appendonly yes // 有一些版本默认注释掉。打开注释设置yes或者no即可 打开/关闭 开启之后从现在开始 每当 Redis 执行一个改变数据集的命令时比如 SET 这个命令就会被追加到.aof文件的末尾。 这样的话 当 Redis 重新启动时 程序就可以通过重新执行.aof文件中的命令来达到重建数据集的目的。
触发方式
同样的我们可以配置Redis多久才将数据同步到磁盘一次。.aof的触发方式同样也有两种自动和手动。 【自动触发】的方式如下Redis提供给我们的需要自己手动打开、关闭 appendfsync always每次有新命令追加到 AOF 文件时就执行一次 fsync 非常慢也非常安全。 appendfsync everysec每秒 fsync 一次足够快并且在故障时只会丢失 1 秒钟的数据。 appendfsync no从不 fsync 将数据交给操作系统来处理。更快也更不安全的选择。 推荐并且也是默认的措施为每秒 fsync 一次 这种 fsync 策略可以兼顾速度和安全性最多丢失最近1秒的缓存数据。
AOF重写
.aof文件里可能有太多没用指令所以【AOF策略】会定期根据内存的最新数据生成aof文件。例如执行了如下几条命令
127.0.0.1:6379 incr readcount
(integer) 1
127.0.0.1:6379 incr readcount
(integer) 2
127.0.0.1:6379 incr readcount
(integer) 3
127.0.0.1:6379 incr readcount
(integer) 4
127.0.0.1:6379 incr readcount
(integer) 5重写后AOF文件里变成
*3
$3
SET
$2
readcount
$1
5如下两个配置可以控制AOF自动重写频率
// aof文件至少要达到64M才会自动重写文件太小恢复速度本来就很快重写的意义不大
# auto-aof-rewrite-min-size 64mb // aof文件自上一次重写后文件大小增长了100%则再次触发重写
# auto-aof-rewrite-percentage 100优缺点
优点是数据安全性相对【RDB】方式来说高点 缺点是恢复速度慢因为不是二进制且需要通过【重放】的方式恢复
1.3 RDB和AOF对比怎么选
命令RDBAOF启动优先级低高文件大小小大恢复速度快慢数据安全性容易丢失数据根据策略决定但整体比较高
上面提到的启动优先级什么意思呢意思是当Redis启动时会优先读取.aof的文件其次才是.rdb。为什么呢因为.aof文件的数据安全性相对可靠一点啊 那我该选择哪一种持久化策略呢其实在生产环境中可以都启用。反正Redis启动时如果既有.rdb文件又有.aof文件的时候会根据优先级选取。
1.4 Redis4.0 混合持久化AOF RDB
基本介绍
不出意外当出现比较特点比较极端的两个方案时总会有一个折中的方案出现。这就是Redis在4.0之后的版本推出的【混合持久化AOF RDB】方式。 重启Redis时我们很少使用.rdb来恢复内存状态因为会丢失大量数据。我们通常使用.aof日志重放但是重放.aof日志性能相对.rdb来说要慢很多这样在Redis实例很大的情况下启动需要花费很长的时间。Redis 4.0 为了解决这个问题带来了一个新的持久化选项——混合持久化
开启/关闭方式 PS混合方式的开启必须要先开启AOF 开启/关闭方式进入程序的目录修改redis.conf配置文件。开启/关闭需要修改如下参数 # appendonly yes # aof-use-rdb-preamble yes // 需要同时上面的参数也为yes才可开启 混合持久化aof文件内容
如果开启了混合持久化AOF在重写时不再是单纯将内存数据转换为RESP命令写入AOF文件而是将重写这一刻之前的内存做RDB快照处理并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起都写入新的.aof文件新的文件一开始不叫appendonly.aof等到重写完新的.aof文件才会进行改名覆盖原有的.aof文件完成新旧两个.aof文件的替换。 于是在 Redis 重启的时候可以先加载.aof文件中的RDB内容然后再重放增量AOF日志就可以完全替代之前的.aof全量文件重放因此重启效率大幅得到提升。 混合持久化AOF文件结构如下
1.5 Redis数据生产备份策略
写crontab定时调度脚本每小时都copy一份rdb或aof的备份到一个目录中去仅仅保留最近48小时的备份每天都保留一份当日的数据备份到一个目录中去可以保留最近1个月的备份每次copy备份的时候都把太旧的备份给删了每天晚上将当前机器上的备份复制一份到其他机器上以防机器损坏
二、Redis主从架构——基础
Redis主从架构模型如下 由上图可以看出在主从结构中通常从节点只做【读】业务【写】业务通常还是由主节点master完成。并且它目前并没有我们小白以为的【宕机自动切换新的主节点】的能力。PS我以前一直听说什么Redis集群高可用节点宕机依然不影响业务所以我乍一看【主从架构】就以为它已经有这个能力了。而事实上并没有它只是【缓解了节点压力】并不具备自动切换
2.1 主从架构搭建
好记性不如多操作几遍 redis主从架构搭建配置从节点步骤如下
复制一份redis.conf文件例如我在我的redis下就复制了两份并且分别命名为redis-6380.conf和redis-6381.conf因为我计划搭建【一主二从】的结构 将相关配置修改为如下值以redis-6380.conf为例一定要确保全部都修改到了不然很可能就因为你忽略了的一个修改导致同步不生效
# 修改从节点的运行端口
port 6380# 把pid进程号写入pidfile配置的文件
pidfile /var/run/redis_6380.pid# 日志文件命名
logfile 6380.log# 指定数据存放目录需要提前在redis-6380.conf的当前目录下新建好data目录及其下面的slave-80目录
dir ./data/slave-80 # 需要注释掉bind
# bind绑定的是自己机器网卡的ip如果有多块网卡可以配多个ip
# 代表允许客户端通过机器的哪些网卡ip去访问
# 内网一般可以不配置bind注释掉即可
# bind 127.0.0.1继续修改配置这个是配置【主从复制】的核心以redis-6380.conf为例
# 从本机6379的redis实例复制数据Redis 5.0之前使用slaveof
# 格式replicaof [master节点的up地址] [master节点的端口6379]
# 比如我的是下面这个
replicaof 127.0.0.1 6379# 配置从节点只读默认打开了
replica-read-only yes 然后就可以启动从节点了
# redis-6380.conf文件务必用你复制并修改了之后的redis.conf文件
./src/redis-server ./redis-6380.conf 使用redis-cli -p 端口的方式连接到对应的从库校验一下测试在6379端口的master实例上写数据看看6380和6381端口的slave实例是否能及时同步新修改数据。我的测试数据如下 如上所示我在6379主节点设置了一个name值为helloRedis接下来我们去从节点看看 看6380端口跟6381端口的从节点都同步了数据
2.2 Redis主从工作原理
Redis主从工作原理其实并不是那么神奇主要是保证数据一致性就好了。那该怎么保证呢首先肯定是要分场景的。比如第一次过来同步复制全量同步之前已经同步过一次了但后来因为某些原因断了现在重新连接上需要继续同步最近的数据增量同步断点续传。 下面再给大家看看【全量同步】跟【增量同步】的业务流程图
全量同步业务流程图 如果你为master配置了一个slave不管这个slave是否是第一次连接上Master它都会发送一个PSYNC命令给master请求复制数据master收到PSYNC命令后会在后台进行数据持久化通过bgsave生成最新的.rdb快照文件持久化期间master会继续接收客户端的请求它会把这些可能修改数据集的请求缓存在内存中当持久化进行完毕以后master会把这份.rdb文件数据集发送给slaveslave会把接收到的数据进行持久化生成.rdb然后再加载到内存中然后master再将之前缓存在内存中的命令发送给slave当master与slave之间的连接由于某些原因而断开时slave能够自动重连master如果master收到了多个slave并发连接请求它只会进行一次持久化而不是一个连接一次然后再把这一份持久化的数据发送给多个并发连接的slave
小总结 上面在生成持久化文件的时候有两个要点不知道大家注意到没有那就是bgsave跟.rdb。 前面的bgsave比较好理解异步生成.rdb文件嘛为了不阻塞主节点的客户读写。那为什么是.rdb而不是.aof呢其实说来也不算难理解只不过我估计大家刚接触【redis持久化】所以比较陌生而已。因为.rdb恢复速度快啊二进制文件嘛。
增量同步业务流程图 当master和slave断开重连后一般都会对整份数据进行复制。但从redis2.8版本开始redis改用可以支持部分数据复制的命令PSYNC去master同步数据slave与master能够在网络连接断开重连后只进行部分数据复制断点续传master会在其内存中创建一个复制数据用的缓存队列缓存最近一段时间的数据master和它所有的slave都维护了复制的数据下标offset和master的进程id因此当网络连接断开后slave会请求master继续进行未完成的复制从所记录的数据下标开始。如果master进程id变化了或者从节点数据下标offset太旧已经不在master的缓存队列里了那么将会进行一次全量数据的复制
主从复制风暴
什么是主从复制风暴简单来说就是一个主节点需要应付很多从节点的复制请求就算是采用异步执行同步命令但是当数据多了之后也会容易陷入瓶颈。这就是主从复制风暴。 为了缓解主从复制风暴多个从节点同时复制主节点导致主节点压力过大可以做如下架构让部分从节点与从节点与主节点同步同步数据
代码实战
这里新建一个SpringBoot项目然后试着跑一下代码看看主从是否真的生效。 首先在pom.xml里面引入如下配置
!-- springboot--
dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot/artifactIdversion2.7.0/version/dependency!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-data-redis --dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-data-redis/artifactIdversion2.7.0/version/dependency!-- redis客户端jedis--dependencygroupIdredis.clients/groupIdartifactIdjedis/artifactIdversion2.9.0/version/dependency然后添加如下代码试试看
public class JedisSingleTest {public static void main(String[] args) {JedisPoolConfig jedisPoolConfig new JedisPoolConfig();jedisPoolConfig.setMaxTotal(20);jedisPoolConfig.setMaxIdle(10);jedisPoolConfig.setMaxIdle(5);// timeout这里既是连接超时又是读写超时从Jedis 2.8开始有区分connectionTimeout和soTimeout的构造函数JedisPool jedisPool new JedisPool(jedisPoolConfig, 114.132.46.145, 6379, 3000, null);Jedis jedis null;try {// 从redis连接池里拿出一个连接执行命令jedis jedisPool.getResource();System.out.println(jedis.set(single, zhuge));System.out.println(jedis.get(single));} catch (Exception e) {e.printStackTrace();} finally {//注意这里不是关闭连接在JedisPool模式下Jedis会被归还给资源池。if (jedis ! null)jedis.close();}}
}
如上代码运行的时候会往缓存中添加一条keysingle, valuezhuge的数据我们看看效果
三、Redis主从架构——哨兵高可用架构
Redis哨兵高可用架构模型图如下
sentinel哨兵是特殊的redis服务不提供读写服务主要用来监控redis实例节点sentinal哨兵也是redis服务后面我们启动的时候就会知道其实也是使用redis-server来启动的 哨兵架构下client端第一次从哨兵找出redis的主节点后续就直接访问redis的主节点不会每次都通过sentinel代理访问redis的主节点。不过当redis的主节点发生变化哨兵会第一时间感知到并且将新的redis主节点通知给client端这里面redis的client端一般都实现了订阅功能订阅sentinel发布的节点变动消息
小总结 不知道大家看到这个【三】这个标题有没有意识到什么那就是【哨兵模式】其实还是属于【主从架构】。只不过新增了【哨兵】这个角色用来做【节点检测与发现】。一旦真正运行【读写】的Redis实例挂了那么【哨兵】就会即刻感知并且做出反应这就是【哨兵】的职责也是保证架构【高可用】的原理。
3.1 Redis哨兵架构搭建
好记性不如多操作几遍。注意不需要关闭之前的【主从】Redis服务
在程序目录中复制一份sentinel.conf文件这里改名为sentinel-26379.confsentinel-26380.confsentinel-26381.conf三个文件。因为我们后面需要新增3个哨兵
cp sentinel.conf sentinel-26379.conf将相关配置修改为如下值以sentinel-26379.conf为例
# 指定哨兵运行的端口
port 26379# 是否守护线程
daemonize yes# 把pid进程号写入pidfile配置的文件
pidfile /var/run/redis-sentinel-26379.pid# 日志文件命名
logfile 26379.log# 指定数据存放目录需要提前在当前目录下新建好data目录及其下面的sentinal-79目录
dir ./data/sentinal-79继续配置下面的配置是哨兵的核心以sentinel-26379.conf为例
# 格式如下
# sentinel monitor master-redis-name master-redis-ip master-redis-port quorum
# 上面最后一个参数【quorum】是一个数字指明当有多少个sentinel
# 认为一个master失效时值一般为sentinel总数/2 1master才算真正失效
# mymaster这个名字随便取客户端访问时会用到
sentinel monitor mymaster 1xx.1xx.xx.xxx 6379 2PS上面的1xx.1xx.xx.xxx是我的外网地址为什么要填外网地址因为我在后面需要用Java代码演示
启动sentinal哨兵实例
./src/redis-sentinel sentinel-26379.conf 查看sentinel的info信息可以看到Sentinel的info里已经识别出了redis的主从 另外sentinel集群都启动完毕后会将哨兵集群的元数据信息写入所有sentinel的配置文件里去追加在文件的最下面我们查看下如下配置文件sentinel-26379.conf的最末尾如下所示
#代表redis主节点的从节点信息
sentinel known-replica mymaster 127.0.0.1 6380#代表redis主节点的从节点信息
sentinel known-replica mymaster 127.0.0.1 6381#代表感知到的其它哨兵节点
sentinel known-sentinel mymaster 10.0.x.x1 26381 cdd97406fbcb4fdcdbf226f0d8540b1b8ac75d5f#代表感知到的其它哨兵节点
sentinel known-sentinel mymaster 10.0.x.x1 26380 41c32a30f100bb28590ef3fef8e53cf158c1b6a7当redis主节点如果挂了哨兵集群会重新选举出新的redis主节点同时会修改所有sentinel节点配置文件的集群元数据信息比如6379的redis如果挂了假设选举出的新主节点是6380则sentinel文件里的集群元数据信息会变成如下所示
#代表主节点的从节点信息
sentinel known-replica mymaster 127.0.0.1 6379#代表主节点的从节点信息
sentinel known-replica mymaster 127.0.0.1 6381#代表感知到的其它哨兵节点
sentinel known-sentinel mymaster 10.0.x.x1 26380 52d0a5d70c1f90475b4fc03b6ce7c3c56935760f#代表感知到的其它哨兵节点
sentinel known-sentinel mymaster 10.0.x.x1 26381 e9f530d3882f8043f76ebb8e1686438ba8bd5ca6当然还会修改sentinel文件里之前配置的mymaster对应的6379端口改为6380
sentinel monitor mymaster 1xx.1xx.xx.xxx 6380 2当6379的redis实例再次启动时哨兵集群根据集群元数据信息就可以将6379端口的redis节点作为从节点加入集群
3.2 哨兵架构高可用工作原理
后面再总结…
3.3 代码实战
这里新建一个SpringBoot项目然后试着跑一下代码看看主从是否真的生效。 首先在pom.xml里面引入如下配置
!-- springboot--dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot/artifactIdversion2.7.0/version/dependency!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-data-redis --dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-data-redis/artifactIdversion2.7.0/version/dependency!-- redis客户端jedis--dependencygroupIdredis.clients/groupIdartifactIdjedis/artifactIdversion2.9.0/version/dependencydependencygroupIdorg.apache.commons/groupIdartifactIdcommons-pool2/artifactIdversion2.7.0/version/dependency接着再添加application.yml如下
spring:redis:database: 0timeout: 3000sentinel: #哨兵模式master: mymaster #主服务器所在集群名称nodes: 1xx.1xx.xx.xxx:26379,1xx.1xx.xx.xxx:26380,1xx.1xx.xx.xxx:26381lettuce:pool:max-idle: 50min-idle: 10max-active: 100max-wait: 1000然后添加如下代码试试看
public class JedisSingleTest {public static void main(String[] args) {JedisPoolConfig config new JedisPoolConfig();config.setMaxTotal(20);config.setMaxIdle(10);config.setMinIdle(5);String masterName mymaster;SetString sentinels new HashSetString();sentinels.add(new HostAndPort(114.132.46.145, 26379).toString());sentinels.add(new HostAndPort(114.132.46.145, 26380).toString());sentinels.add(new HostAndPort(114.132.46.145, 26381).toString());// JedisSentinelPool其实本质跟JedisPool类似都是与redis主节点建立的连接池// JedisSentinelPool并不是说与sentinel建立的连接池而是通过sentinel发现redis主节点并与其建立连接JedisSentinelPool jedisSentinelPool new JedisSentinelPool(masterName, sentinels, config, 3000, null);Jedis jedis null;try {jedis jedisSentinelPool.getResource();System.out.println(jedis.set(sentinel, zhuge));System.out.println(jedis.get(sentinel));} catch (Exception e) {e.printStackTrace();} finally {// 注意这里不是关闭连接在JedisPool模式下Jedis会被归还给资源池。if (jedis ! null)jedis.close();}}
}小总结 不知道大家看了上面的代码有没有发现我们都不用配置Redis的相关信息了而是改成配置【哨兵】。没毛病我们在最上面的模型里面已经说了我们的节点信息是从【哨兵】获取的。
学习总结
学习了Redis的主从架构并且尝试自己在云上配置普通的主从架构学习了Redis主从架构之哨兵模式并且尝试自己在云上配置
