当前位置: 首页 > news >正文

Redis-主从复制-分布式系统

目录

1.部署方式:

2.主从模式:

3.配置redis主从结构

指定redis的端口号:

配置主从结构:

查看主从结构:

断开主从关系:

连接新的主节点:

安全性:

只读:

传输延迟:

4.拓扑结构:

1.一主一从:

2.一主多从:

3.树形结构:

5.复制过程

数据同步 psync:

replication 复制:

offset偏移量:


在分布式系统中存在一个非常重要的问题:单点问题.

若某个服务器只有一个节点(只使用一台物理服务器来部署服务器程序),就面临很多问题:

1.可用性问题.若这个服务器挂了,服务也就中断了.

2.并发问题,性能较低,支持的并发量非常有限.


在分布式系统中,往往希望使用多个服务器来部署redis服务,从而构成一个redis集群,这就可以让这个redis集群给给整个分布式系统的其他服务提供更加高效可靠的服务了.

1.部署方式:

在分布式系统中,存在3种redis的部署方式:

1.主从模式

2.主从+哨兵模式

3.集群模式

2.主从模式:

在多个redis节点中,有的是主节点,有的是从节点;

主节点将数据同步给从节点,只能从从节点上读数据,不能写数据,只有主节点有读写数据的权限.也就是说从节点要停主节点的.

主从模式主要是针对"读操作"进行的并发量和可用性的提高. 解决了上面提到的单节点的的两个问题.

在主节点上存储一些数据,主节点将这些数据同步给从节点,在实际的应用场景中,更多的是对数据的读操作,写操作相对较少,当读数据的时候,可以从从节点中读取,分散主节点的读取工作量,这也是比较符合实际逻辑的.

主从节点就类似于老师和助教的关系,老师讲课,助教先接收老师讲的知识,然后有同学有不懂的,可以通过老师询问,也可以通过助教解答;但助教不能给同学加新的知识,否则会出现偏差.

对于的单个redis服务器来说,当这个服务器挂了,整个redis系统也就挂了;

对于redis集群来说:

从节点服务器出现挂了等情况,可以主节点或从其他从节点去读取数据,效果相同,是不受影响的.

主节点服务器挂了,在写操作上会受到影响,因为只有主节点才能执行写操作.读还是不受影响的.

为了更高的提高服务器的可用性,通常将多个redis服务器放在不同的机房中,防止机房出现问题,导致所有服务器挂了的情况.

3.配置redis主从结构

由于当前手中只有一个云服务器,因此将 主节点和多个从节点都部署到同一台云服务器上,(原则上是要不部署在不同的机房的不同的服务器上,才构成分布式).但运行不同的redis的端口号要不同.

redis的默认端口号为6379,

现在部署一台主节点,端口号为6379; 两个从节点,端口号设为6380和6381.

指定redis的端口号:

有两种方法:
1.在启动程序的时候,通过命令行的方式,指定端口号. --port选项

2.通过配置文件修改端口号.

主节点的端口号不变,只需要修改从节点的端口号即可:

现在先将redis的配置文件复制两份:slave1.conf ,slave2.conf,保存到创建的redis-conf文件夹中

进入配置文件,进行修改:

要修改两个地方:

1.端口号6379->6380

2.将daemonize设置为yse,有的默认已经为yes.

这个配置的意思是让redis按照后台进程运行.

同样的操作,将slave2.conf也进行修改,将端口号改为6381,daemonize设为yes:

启动redis进程:

通过redis-server ./配置文件名 命令启动redis:

通过pa aux | grep redis命令查询当前主机上的redis进程:可以看到除了有6379的redis端口号,还有两个6380,6381端口也已经启动.

此时多个redis服务器是已经启动了,但他们之间还不存在关系,需要再进行配置,让他们相互之间构成主从结构.

配置主从结构:

配置主从结构的方法也有好几种:

1. 在配置⽂件中加⼊ slaveof {masterHost} {masterPort} 随 Redis 启动⽣效。

2. 在 redis-server 启动命令时加⼊ --slaveof {masterHost} {masterPort} ⽣效。

3. 直接使⽤ redis 命令:slaveof {masterHost} {masterPort} ⽣效

这里使用第一种,在配置文件中配置.

通常情况下,更倾向于需改配置文件,因为在配置文件中的操作是永久生效的,即使服务器挂了了,重启服务器,配置文件也是能立即生效的; 但是若通过命令等方式,当重启服务器的时候,原来的配置就不存在了,需要重新配置.

打开配置文件,在文件末尾加上配置:将两个从节点配置文案都进行配置.

保存并退出配置文件,然后重启服务器.才会生效.

先将两个从节点redis进程杀死:

注意:这里使用kill -9的命令杀死进程,而不是使用service redis-server restart的方式重启,是因为启动的时候,是通过运行redis-server命令的方式,这个要搭配kill -9使用.

若通过service redis-server start的命令启动,就必须使用service redis-server stop的命令来停止,这时,若使用kill -9的命令停止进程,是无法停止的,该命令执行后,会立即有新的进程启动.因为服务器要维持高可用行和稳定性,当服务器异常挂了,要尽快采取补救措施,以减少带来的影响.

这里会有另外的进程监控这些进程的状态,一旦异常挂了,就会立即重启一个新的进程.

此时再查看redis进程,就剩一个主节点进程了:

现在再将两个从节点进程启动起来:

再次查看redis的进程ip,就会发现3个进程都已经启动了.都处于listen状态.

可以看到,下面还有3条信息:

由于当前的3个redis进程都是在同一个云服务器上的,主节点就相当于服务器,从节点就相当于客户端,是站在不同的角度,看到客户端连接服务器和服务器连接客户端都在同一个云服务器上,于是就都显示出来了.

查看主从结构:

先展示一下效果:

接着就可以进入redis客户端了:

进入主节点客户端:插入一条数据:

进入一个从节点客户端:

查询刚在主节点中存储的数据:可以查询到,

再进入另一个从节点查看:

当向两个从节点中写数据时,都是不允许的,都是只读权限:

查看相关信息:

通过info replication命令查看:

查看从节点信息:

主节点写入的数据并不是瞬间同步到从节点的,是有一定的延迟的,特别是数据特别多的时候,

offset字段就是记录当前同步的进度.

断开主从关系:

可以直接通过redis里的 slaveof  no one命令,断开主从关系.

现在将6381端口的redis服务器断开:

再次查看该节点的信息:

可以看到,该节点的身份已经是主节点了.

此时再查看主节点6739的相关信息:

此时,6379的从节点就只剩下一个6380了,6381已经脱离该主节点的控制了.

此时6381虽然已经不再是6379的子节点的,但原来已经同步到6381上的数据还是存在的,只是之后的数据就不会再同步.

连接新的主节点:

还可以通过 slaveof  ip 端口号 的命令连接其他端口,让另一个服务器作为其主节点:

再查看其信息,就会发现它又变成了一个从节点,并且主节点也发生了变化:

再来查看6380的信息:

它还是从节点,但它又连接了一个从节点,端口号为6381.

此时主从节点的连接变化:

此时,6380端口号的服务器虽然也是一个主节点了,但还是没有写的权限,仅是通过它将信息传递给6381,并不是真正的主节点.

注意: 但是这种通过命令的方式断开主节点的方式是临时性的,当服务器重启后,还是要根据配置文件中配置的信息进行连接,并不是永久性的,要想让其永久生效,还是要修改配置文件才行.

此时重启6381的服务器:

再查看节点的连接关系,6381又成为了6379的一个从节点,回复到了刚开始的样子.

安全性:

对于数据⽐较重要的节点,主节点会通过设置 requirepass 参数 进⾏密码验证,这时所有的客⼾端访问必须使⽤ auth 命令实⾏校验。从节点与主节点的复制连接是通过⼀个特殊标识的客⼾端来完成,因此需要配置从节点的masterauth 参数与主节点密码保持⼀致,这样从节点才可以正确地连接到主节点并发起复制流程。

只读:

默认情况下,从节点使⽤ slave-read-only=yes 配置为只读模式。

由于复制只能从主节点到从节点,对于从节点的任何修改主节点都⽆法感知,修改从节点会造成主从数据不⼀致。所以建议线上不要修改从节点的只读模式。

传输延迟:

主从节点⼀般部署在不同机器上,复制时的⽹络延迟就成为需要考虑的问题.

Redis 为我们提供了 repl-disable-tcp-nodelay 参数⽤于控制是否关闭 TCP_NODELAY,默认为 no,即开启 tcpnodelay 功能,

开启此功能,会节省网络带宽,但会增加tcp传输延迟;

关闭时,会消耗网络带宽,但会降低tcp传输延迟.传输数据速率会更快.

它和tpc的捎带应答有相同的功效,针对小的tcp数据报进行合并,减少了包的个数

4.拓扑结构:

若干个节点之间,按照不同的方式来组织连接.

1.一主一从:

一个主节点,一个从节点.是最简单的拓扑结构.

⽤于主节点出现宕机时从节点提供故障转移⽀持。

从节点可以分担读数据的请求.但是写数据的请求从节点无法分担,为了减少主节点的任务,可以把主节点的aof文件关闭,仅让从节点进行数据备份.

但是, 这样又会带来一个很严重的后果,一旦主节点挂了,由于主节点的数据都在内存上保存的,并没有备份,就会全部消失,当主节点再次重启时,由于数据都消失了,进一步主从同步,就会把从节点中的数据都删了.

因此,当主节点服务器挂了后,不能立即启动,要让主节点从从节点这里恢复原来的数据.再启动.

2.一主多从:

一个主节点,连接多个从节点.

开发中,读命令要远多于写命令,因此这个结构可以把读命令负载均衡到不同的从节点上来分担压⼒。

这种结构带来的缺点:

对主节点的带宽有较高的要求,因为主节点的数据发生修改后,要同步给所有的从节点,当连接的从节点数量很多时,传输一条数据,就需要传输多次.因此就需要主节点的带宽性能较高.

3.树形结构:

一个主节点,有多个从节点,从节点还连接一些从节点.

这个结构就解决了上面一主多从的网络带宽问题.最主节点的网络带宽没有那么大的要求了.

但这个结构有出现的问题是:

由于数据的传输要进行多级传输,因此就会增加数据传输延迟性.

5.复制过程

从节点从主节点同步数据的流程如下:

1.保存主节点信息:

从节点会保存主节点的ip和端口号,一便之后的同步.

2.主从建立连接:

就是完成tcp的三次握手.建立连接,确认通信路径时正常通畅的.

3.发送ping命令:

从节点发送ping命令, 验证主节点能否正常工作.

这个和第二步的建立连接是不同的,这个是站在应用程序的层面上验证.建立连接是在系统层面上的连接.建立连接就好像运输货物,验证路是否通畅且能正常走,而发送ping命令是验证货车是否能正常拉货运输.

4.权限验证:

当主节点开启了密码,从节点建立连接关系的时候,就要输入正确的密码才能进行数据同步.起到数据保护作用.

5.同步数据集:

当第一次进行主从同步的时候,就要将主节点中的所有数据都同步到从节点上.

6.命令持续复制:
第一次同步后,之后主节点每进行数据修改,都要持续同步到从节点上.

将在下一篇文章介绍第5,6步 主从同步的详细流程.

http://www.dtcms.com/a/268369.html

相关文章:

  • 算法学习day15----蓝桥杯--进制转换
  • Web攻防-XMLXXE无回显带外SSRF元数据DTD实体OOB盲注文件拓展
  • 大数据Hadoop之——Flink1.17.0安装与使用(非常详细)
  • 桥梁桥拱巡检机器人cad+【4张】设计说明书+绛重+三维图
  • 了解微服务
  • JVM的内存区域划分,类加载器和GC
  • Modbus 与 BACnet 协议互操作:工业协议转换方案(一)
  • JavaSE -- 泛型详细介绍
  • 【机器学习笔记 Ⅱ】2 神经网络中的层
  • HCIA-生成数协议(STP)
  • Debezium日常分享系列之:Debezium管理平台
  • 【Elasticsearch入门到落地】15、DSL排序、分页及高亮
  • golang 协程 如何中断和恢复
  • WHAT - 依赖管理工具 CocoaPods
  • 从小白到进阶:解锁linux与c语言高级编程知识点嵌入式开发的任督二脉(1)
  • 如何确保Kafka集群的高可用?
  • 【MySQL】DTS机制对触发器时间的影响
  • Python-可视化学习笔记
  • 【机器学习笔记Ⅰ】3 代价函数
  • 空调和烘干机的使用
  • pyhton基础【23】面向对象进阶四
  • 爬虫的笔记整理
  • 在Ubuntu 24.04上部署Zabbix 7.0对服务器进行监控
  • Grok 4 最新技术评测与发布指南
  • 位置编码和RoPE
  • 光纤的最小弯曲半径是多少?
  • 商业秘密攻防战:技术信息与经营信息的界定之道
  • 基于Flask和机器学习开发的米其林餐厅数据可视化平台
  • 爬虫-request模块使用
  • CSS05:结构伪类选择器和属性选择器