Redis进阶(三):主从复制

为了解决单点问题，实现多服务器部署redis，有几种解决方案可以实现：主从复制，主从+哨兵还有集群。

何为主从复制

简单来说有三个服务器分别部署了redis-server程序，选中一个服务器当作主节点，其他的就是从节点了。主节点上有一堆的数据，复制出来拷贝到从节点上，后续主节点有任何修改的数据，都要在从节点上体现出来，要注意的时候为了避免从节点影响到主节点，从节点只能读，不能写。

主从解决的问题

在可用性方面，如果是单机结构，机器挂了整个程序就挂了，如果是主从结构的话，大大提高了程序的可用性。

在性能方面来看，由于从节点的数据时刻保持和主节点一致，那么客户端从从节点访问数据和从主节点访问数据是一致的，后续如果有大量的客户端访问数据的话，平均下来，各个节点的压力减少了不小。这其实也相当于引入了计算机资源，并发量自然提升了。

更准确来说主从只针对读操作进行并发量可用性的提高，而写操作依赖于主节点，但是主节点又不能搞多个。

单机部署多个redis

单机情况下部署redis的前提那就是，不同的redis需要有着不同的端口，修改端口常用的有俩种方式，一个是修改配置文件，另一个就是--port命令行来实现。

修改新复制的配置文件端口分别改成6380 和 81

当前这几个redis并没有构成主从结构

由于主从建立了连接，主节点数据一发生改变，从节点立马感知到。而且从节点没办法写数据（set）

了解主从结构（info命令）

断开主从关系/修改主从关系

slaveof no one

直接在客户端使用这个命令断开现有的主从复制关系，此时从节点就不属于任何主节点了，自己变成主节点了

要注意的是删除的只是关系，从节点的数据不会发生改变的

使用slaveof修改只是暂时的，重新启动redis优惠恢复如初。

安全性、只读、传输延迟

对于数据比较重要的节点，主机点通过设置requirepass参数进行密码验证，这时所有的客户端访问必须使用auth命令进行验证，从主节点之间的数据复制是一个特殊的客户端来完成的，因此需要配置从节点的masterauth参数与主节点密码保持一致，这样才能连接并且复制。

从节点不允许修改文件，只能进行读操作。最好不要修改，因为主节点无法感知从节点数据修改的。

主从节点一般是不同的机器上的，要考虑到传输延迟，而主从节点的交互是靠网络传输的，也就是tcp。TCP内部支持了nagle算法，开启了会增加传输延迟，但是节省了网络带宽，关闭了减少网络延迟，增加网络带宽，究其原因是nagle算法相当于把tcp数据包打包起来，针对小的数据包进行合并，减少了包的个数。

拓扑

首先，拓扑的含义是若干个节点之间，按照啥样的方式进行组织连接？

一主一从

客户端发生读请求既可以向主节点发送也可以发送给从节点，但是写请求只能发给主节点，会对主节点造成不小的压力，因此我们可以通过关闭主节点的AOF，打开从节点的AOF，但是这种是有缺陷的，主节点一旦挂掉，会自动启动，此时主节点又没有AOF文件，那么从节点还没来得及保存的数据又会丢失了，优化办法是，当主节点挂了，需要让主节点向从节点要AOF文件，再启动。

一主多从

主从复制流程

从节点接收到slaveof指令之后，从节点第一步就首先记录主节点的信息（ip、端口号之类的），当然是通过变量的形式记录，在那之后主从之间要建立连接，使用的是tcp建立连接（三次握手），然后是通过发送ping看功能命令能否正常使用，再者就是有的时候主节点会设置密码，因此会出现权限验证的环节，后面就是同步数据集和命令持续复制了。

redis提供了psync命令来完成数据同步的过程，不需要手动执行的，主从关系建立成功之后，会自动执行psync，从节点负责从主节点拉取数据。