网站建设基础问题,品牌建设工作机制,宁波建设网官网,东莞网站建设公司企业目录 前言
一、主从模式
1.1、概述
1.2、配置 redis 主从结构
1.2.1、复制配置文件#xff0c;修改
1.2.2、配置主从结构
1.2.3、启动 redis 服务
1.2.4、查看复制状态
1.3、slaveof 命令
1.3.1、断开主从复制关系
1.3.2、切换主从复制关系
1.3.3、只读
1.3.4、网…目录 前言
一、主从模式
1.1、概述
1.2、配置 redis 主从结构
1.2.1、复制配置文件修改
1.2.2、配置主从结构
1.2.3、启动 redis 服务
1.2.4、查看复制状态
1.3、slaveof 命令
1.3.1、断开主从复制关系
1.3.2、切换主从复制关系
1.3.3、只读
1.3.4、网络延迟问题
1.4、拓扑结构
1.4.1、一主一从
1.4.2、一主多从
1.4.3、树形主从
1.5、主从复制流程
1.5.1、大致流程
1.5.2、数据同步
areplication id
boffset
psync 运行流程
全量复制流程
部分复制流程
实时复制流程
心跳包
误区runid 是什么?
1.6、 拓展主从结构配置误区配置前必看 前言 谈到分布式系统涉及到一个关键问题单点问题
如果一个服务器只有一个节点只用一个物理服务器部署整个程序那么出现以下问题
可用性如果这个机器挂了意味着服务就中断了.性能支持的并发量也是比较有限的.
因此引入分布式系统主要也是为了解决上述的单点问题~ 分布式系统中往往需要多个服务器来部署 redis 服务从而构成 redis 集群此时就可以让这个集群给整个分布式系统中的其他服务提供更稳定 / 更高效的数据存储功能.
本章主要来讲一下 redis 部署方式中的主从模式. Ps本章节相关操作不需要记忆后续工作中如果用到了能查到即可. 重点理解流程和原理. 一、主从模式 1.1、概述 在 redis 主从模式下由一个主节点和多个从节点构成所谓一山不能容二虎从节点通过复制主节点得到并且后续主节点数据发生变化从节点也必须 “听” 主节点的从节点的数据跟随主节点一起变化保持一致 .
如果我修改了从节点的数据呢redis 主从模式中从节点上的数据不允许修改只能读取数据而主节点既可以进行 “写操作” 也可以进行 “读操作” ~ 为什么这么搞呢实际上更准确的说主从模式主要是针对 “读操作” 进行 并发量 可用性 的提高因为实际的业务场景中读操作往往比写操作更频繁~ 如果节点挂了怎么办 如果是挂掉了某一个从节点没什么影响此时继续从主节点或者其他从节点读取数据效果是完全一样的.
如果改掉的是主节点是有一定影响的因为主节点还负责 “写数据” . 这样结构的好处 由于从节点的数据和主节点时刻保持一致因此其他客户端从从节点这里读取数据和主节点这里读取数据是没区别的 如果后续有客户端来读取数据就可以从节点中随便挑一个来读取数据引入更多的资源支持的并发量也就大大提高了~ 举个例子 从节点就像是刚到公司的实习生是不能在没有熟悉业务和文档的前提下去干活的因此刚来的实习生任务只有一个就是熟悉业务读操作而你的导师就像主节点只能有一个他的工作就是完成自己需求写操作读操作并且他来告诉你你要去读什么文档、熟悉什么业务从节点通过复制主节点得到. 1.2、配置 redis 主从结构
配置 redis 主从结构需要启动多个 redis 服务器分配在一个个单独的主机上分布式但是考虑到我们目前每个人大概只有一个云服务器因此就来实现一下在一个云服务器主机上运行多个 redis-server 进程~
本来 redis-server 的端口是 6379 此时就不能让其他节点启动时也用 6379 了我们有一下两种方式来指定 redis-server 的端口号
启动程序时通过命令的方式来指定端口号--port 选项直接在配置文件中来设定端口推荐因为修改配置文件是持久有效的. 假设我要配置一个主节点和两个从节点步骤如下 1.2.1、复制配置文件修改
主节点的配置不变只需要修改从节点的配置即可因此我们只需要复制两份主节点的配置文件并修改这两份文件的端口和后台运行方式即可. 1.2.2、配置主从结构
在两个配置文件末尾加 slaveof 配置主从结构绑定父节点为 6379 端口. 1.2.3、启动 redis 服务 通过 redis-server 命令来启动刚刚配置好的这两个节点. Ps如果 redis 服务启动后修改了配置文件就需要重启才能起效。 1.如果是通过 redis-server 启动服务器就必须搭配 kill 命令来停止. 2.如果是通过 service redis-server start 启动服务器必须搭配 service redis-server stop 来停止. 3.如果使用 kill 命令停止 service redis-server start 这个 redis-server 进程会自动启动. 通过 netstat -anp 命令就可以查看从节点和主节点的绑定情况 在复制两个会话启动两个从节点的 redis 客户端此时 redis 从节点上就只能读数据不能写入数据了 1.2.4、查看复制状态
在 redis 客户端通过 info replication 就可以查看当前节点的复制状态了. 这里简单看一下后面有详细介绍~
值得注意的是从节点和主节点之间的数据同步不是瞬间完成的并且同时主节点上也会 “源源不断” 的收到其他 “修改数据” 的请求因此这个时候就需要使用 offset 来记录当前主节点和从节点的数据同步情况当 从节点 的 offset 等于 主节点的 offset 时表明此时数据完全一致. 1.3、slaveof 命令
1.3.1、断开主从复制关系
在当前从节点的 redis 客户端中使用 slaveof no one 可以断开现有的主从复制关系并且自身成为新的主节点~ Ps这里从节点断开复制后并不会抛弃原有数据只是无法再获取主节点上的数据变化这就像是你是一个土匪加入了别人的帮派几年以后感觉自己学了不少东西于是就脱离了现在的帮派自己出来占山为王~ 1.3.2、切换主从复制关系
通过 slaveof 命令还可以实现切主操作将当前从节点的数据源切换到另⼀个主节点并且切换后会先删除当前节点的所有数据再复制新的主节点数据。执行 slaveof {newMasterIp} {newMasterPort} 命令即可。
例如将端口号为 6381 从节点的 “主”换成 端口号为 6380如下 Ps此处的修改是临时的如果重启 redis 服务器就会按照最初再配置文件中设置的内容来建立主从关系. 1.3.3、只读
默认情况下从节点使⽤ slave-read-onlyyes 配置为只读模式。由于复制只能从主节点到从节 点对于从节点的任何修改主节点都⽆法感知修改从节点会造成主从数据不⼀致。所以建议线上不 要修改从节点的只读模式。 1.3.4、网络延迟问题
TCP 内部支持 naqle 算法目的就是为了节省网络带宽目的和 tcp 的捎带应答一样针对小的 tcp 数据报就多攒点攒够了再发这样就减少了发送的次数。通过 repl-disable-tcp-nodelay 这个选项就可以进行配置 naqle 算法是否开启.
值得注意的是实际的工作中需要根据实际场景来决定是否开启
开启能节省网络带宽但是会增加 tcp 的传输延迟.关闭能减少 tcp 传输延迟但是会增加网络带宽.
一般游戏开发或者是视频直播这种即时性要求特别强的就像需要关闭 naqle 算法. 1.4、拓扑结构
拓扑结果就描述了若干个节点之间按照什么样的方式进行组织连接的. 1.4.1、一主一从 这种结构有一个特点就是当写请求的数据太多的时候也会给主节点带来压力可以通过关闭主节点的 AOF 只在从节点上开启 AOF 来分担持久化压力避免影响性能。
但是这种设定方式有一个缺陷就是主节点一旦挂了就不能让他自动重启如果自动重启此时没有 AOF 文件就会丢失数据进一步的同步到从节点上就会把 从节点的数据也给搞丢了.
改进的办法就是当主节点挂了以后让主节点从从节点这里获取 AOF 文件再启动. 实际的开发中读请求 远远超过 写请求也难辞上述的 一主一从结构就有点难以应对了就需要接下来的一主多从结构来支持 1.4.2、一主多从 这种结构就是适合有大量到 读请求 场景帮助主节点分担大部分的 读请求 压力 但实际随着从节点个数的增加向主节点中写入一条数据就需要同步给多个从节点反而影响性能.
为了解决这个问题就需要引入树形主从~
1.4.3、树形主从 这种结构从节点也可以将其他从节点当作主节点分担了主节点将数据同步到从节点上的压力但是一旦数据进行修改同步的延时是要比刚才更长的. 1.5、主从复制流程 1.5.1、大致流程 保存主节点信息从节点会去保存主节点的 ip 和端口.主从建立连接通过 TCP 三次握手建立连接主要是为了验证通信双方是否能正确的读写数据道路是否是通的.发送 ping 命令验证主节点是否能够正常工作车是否能在这个道路上跑.权限验证redis 主节点如果设置了密码参数就需要先通过密码的验证.同步数据集下面会重点介绍.命令持续复制当从节点复制完主节点的所有数据后主节点还会“源源不断”的收到写请求机会继续将修改后的数据复制到从节点上. 1.5.2、数据同步
Redis 使用 psync 命令完成主从数据同步从节点会自动执行 psync也就是从节点会去主节点这边拉取数据.
psync replicationid offset 这个命令主要就是要理解两个参数replicationid 、offset.
areplication id
replication id 就表示要从那个主节点上获取数据.
replication id 是由主节点生成的生成的时机是在主节点启动的时候会生成同一主节点每次重启生成的 replication id 都是不同的从节点晋升为主节点的时候也会生成。
当从节点和主节点建立了复制关系就会从主节点这边拉取到 replication id.
通过 info replication 可以获取到当前 replication id 的值. 这里还可以看到 replid2但是一般是用不上的有一个情况就是假设有两个节点主节点 A 和 从节点 B如果 A 和 B 通信的过程中出现了网络抖动B 可能就认为 A 挂了就会把 replid 的值交给 replid2然后 B 就会自己成为主节点给自己生成一个 replid此时B 也会记得之前的主节点 A 的 replid就是现在的 replid2。
等后续网络稳定了B 还可以根据 replid2 重新回到 A 的怀抱中~这里需要手动干预但是哨兵机制可以自动完成 打个比方 这就好比你在一个公司干的挺好的觉得自己也成长的足够厉害了于是就出来自己创业但是创业的途中你还和之前公司的老板保持很好的关系突然有一天你公司垮了你就通过保持那层关系回到了之前的那个公司的怀抱~ boffset 从节点和主节点之间的数据同步不是瞬间完成的并且在复制数据的同时主节点上也会 “源源不断” 的收到其他 “修改数据” 的请求那么从节点怎么知道数据已经同步到哪里了呢
主节点和从节点上都会维护一个偏移量整数主节点的偏移量就是把收到的 “写操作” 的命令每个命令都要占几个字节按字节进行累加的.从节点的偏移量就描述了现在从节点这里的数据同步到哪里了.如果从节点的偏移量和主节点偏移量一样了就说明两个节点的数据完全一致了.
在 psync 命令中offset 有两种写法
offset 写作 -1就是获取全量数据.offset 写成具体的正整数就是从当前偏移量位置来进行获取. 打个比方 这就像是一个学习的过程老师在课堂上讲课是一个进度你下来自己巩固老师讲课的内容是另一个进度当你完善巩固赶上的老师进度以后你的知识储备也就差不多和老师讲的大差不差了~ psync 运行流程 从节点发送 psync replid offset 指令主节点根据参数进行解析结合自身情况看是要全量数据同步还是部分数据同步增量数据同步.如果反馈 fullresync 表示进行全量数据同步.如果反馈 continue 表示进行增量数据同步.如果反馈 err 表示错误因为比较老版本的 redis 服务器是不支持 psync 的但是可以使用 sync 来代替redis 1.0.0 就有了. 那么什么时候进行全量复制什么时候进行部分复制呢 全量复制首次和主节点进行数据同步时判断 replication id 不一样或者是在部分复制的时候发现已经超出积压缓冲区的数据范围了也会进行全量复制.部分复制从节点之前从主节点上父之过数据了或者是有网络抖动或者从节点重启而丢失数据大部分数据是一致的. 全量复制流程 从节点发送 psync 命令给主节点由于是第一次进行复制从节点没有主节点的复制偏移量所以偏移量发送为 -1也就是需要进行全量复制.主节点根据命令解析出要进行全量复制返回 fullresync 响应.从节点接受主节点的响应信息并保存.主节点执行 bgsave 一定会重新生成一个新的 rdb 文件因为已有的 rdb 文件和最新的数据可能存在较大差异进行持久化.主节点发送 rdb 文件给从节点从节点会将接收到的 rdb 文件保存到本地硬盘.主节点将生成 rdb 到从节点接收完 rdb 文件期间执行的写命令写入缓冲区等从节点保存完 rdb 文件后主节点再将缓冲区中的数据补发给从节点从节点就会把补发的数据仍然按照二进制格式追加写入到 rdb 文件中保证主从一致.从节点清空自身的旧数据.从节点加载 rdb 文件保证和主节点数据一致.如果从节点加载 rdb 文件完成后并且开启了 aof就会把刚刚加载数据过程中产生的 aof 日志通过 bgrewrite 操作清楚冗余数据并进行整理. Ps除了上述讲到的全量复制主节点进行全量复制的时候也支持 “无硬盘模式”diskless. 主节点生成的 rdb 文件不会直接保存到文件中了而是直接进行网络传输接着从节点也将收到的数据直接进行加载了这样主节点和从节点省下来一系列读写硬盘的操作. 即使引入了无硬盘模式整个操作还是比较重量的比骄耗时的因为网络传输是没法省的相比于网络传输读写硬盘就是小头因为涉及到网络传输就离不开封装和分用的过程... 部分复制流程 当主从节点之间出现网络中断时如果超过了 repl-timeout 时间主节点就会认为从节点故障并中断复制连接.主从连接中断期间主节点会继续接受到 “写请求” 的命令就会把这些命令滞留在积压缓冲区中积压缓冲区就是内存中一个简单的队列会记录最近一段时间修改的数据总量是有限的随着时间的推移就会把之前的旧数据逐渐删除掉。当主从节点网络恢复以后从节点再次连接上主节点.从节点将之前保存的 replication id 和 offset 作为 psync 的参数发送给主节点请求进行部分复制.主节点接收到 psync 请求后进行必要的验证随后根据 offset 去积压缓冲区找合适的数据并响应 continue 给从节点. 如果主节点的 “写请求” 过多超出积压缓冲区的范围就只能进行全量复制了)主节点将积压缓冲区的数据发送给从节点保证一致性. 实时复制流程
从节点和主节点数据同步完成了也就是说这一刻从节点和主节点数据一致了但是之后朱姐带你这边也会 “源源不断” 的收到新的 “写请求” 主节点上的数据就会随之改变这种改变也需要能够同步给从节点.
此时从节点和主节点之间会建立 TCP 长连接然后主节点把自己收到的 “写请求” 修改的数据发给从节点从节点再修改自己内存中的数据. Ps这个过程也是需要时间的正常来说延时是比较短的但是如果是多级从节点的树形结构延时就会上升了. 心跳包
进行实时复制的时候需要保证连接处于可用状态因此引入了心跳包机制.
主节点默认每隔 10s 给从节点发送一个 ping 命令从节点收到就会返回 pong.
从节点默认每隔 1s 就给主节点发起一个特定的请求就会上报当前从节点的复制数据的进度offset.
如果主节点发现从节点通信延迟超过 repl-timeout 配置的值默认 60 秒则判定从节点下线断 开复制客⼾端连接。从节点恢复连接后⼼跳机制继续进⾏。 Ps这里的 10s1s60s 数值都不要去背因为都是可以修改的需要我们去结合实际场景合理分配. 误区runid 是什么?
网上有很多资料都会将 run id 和 replication id 混着说实际上一个 redis 服务器上 replication id 和 run id 都是存在的 runid 主要是用来支撑实现 redis 哨兵功能的和主从复制没有什么关系.
replid 和 offset 共同标识了一个数据集合. 1.6、 拓展主从结构配置误区配置前必看 刚刚所讲的主从配置实际上是有问题的因为最开始创建从节点的配置文件没有改 appendfilename 属性导致生成的 aof 文件路径/文件名 都是同一个 如下图 -rw- 就表示 root 用户可读可写而 r--r-- 就表示这个文件除了 root 意外的用户只有读权限又因为 service redis-server start 启动 redis 服务器是通过 redis 这样的用户来启动的防止权限过高redis 被黑客攻破所以其他节点使用 service redis-server start 启动 redis 服务器无法打开这个文件就启动失败了如何解决呢 解决方案把三个 redis 服务器生成的文件也区分开最靠谱的办法就是直接把三个 redis 服务器的 工作目录 分开修改 配置文件 中的 dir 选项
步骤如下
停止之前的 redis 服务器.删除之前工作目录下生成的 aof 文件或者也可以通过 chown 命令修改 aof 文件所属用户 chown redis:redis appendonly.aof 给从节点创建出新的工作目录并修改从节点配置文件设定成新的目录为工作目录.启动 redis 服务器. 码字不易~
