目录
[数据同步 psync:](#数据同步 psync:)
[replication 复制:](#replication 复制:)
在分布式系统中存在一个非常重要的问题:单点问题.
若某个服务器只有一个节点(只使用一台物理服务器来部署服务器程序),就面临很多问题:
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服务器是已经启动了,但他们之间还不存在关系,需要再进行配置,让他们相互之间构成主从结构.
配置主从结构:
配置主从结构的方法也有好几种:
在配置⽂件中加⼊ slaveof {masterHost} {masterPort} 随 Redis 启动⽣效。
在 redis-server 启动命令时加⼊ --slaveof {masterHost} {masterPort} ⽣效。
直接使⽤ 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步 主从同步的详细流程.